<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 14, 2017 at 7:58 AM, Thomas Caswell <span dir="ltr"><<a href="mailto:tcaswell@gmail.com" target="_blank">tcaswell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am in very supportive of this plan.  <div><br></div><div>For Matplotlib the intention is to do a mpl2.2LTS early 2018 and a mpl3.0 (no major API breaks other than dropping py2 support) summer 2018 with the same meaning of LTS.</div><div><br></div><div>I also had thought about bumping the minimum numpy version of Matplotlib to the first py3 only version when it is out.  There is no technical reason, but it seems nicely symmetric.</div><div><br></div><div>In general we all need to get better about dropping support for old versions of dependencies (I am throwing stones from inside my glass house).  The prolonged support of py2 has warped our idea of how long old versions of things need to be supported and it imposes real costs up and down the stack.</div></div></blockquote><div><br></div><div>My $2c: dropping support for all-but-the-latest numpy is not a great idea. There's no need to support numpy versions that are >3 years old, but supporting 2-4 versions back is something most projects have consistently done, and it has real value. Both in terms of not forcing users to upgrade multiple packages in lock-step, and for things like debugging (is it a new numpy or an mpl bug? --> check if the failure disappears with older numpy).</div><div><br></div><div> Ralf</div><div><br></div></div></div></div>