<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt <<a href="mailto:stefanv@berkeley.edu" target="_blank">stefanv@berkeley.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:<br></div><blockquote type="cite" id="gmail-m_-2189463113052914146gmail-m_1943618322760280026qt"><div dir="ltr"><div dir="ltr">I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that. <br></div></div></blockquote></div></blockquote></div></div></blockquote><div><br></div><div>I'm not sure I like this approach, which is reflected in the current version of <a href="https://github.com/numpy/numpy/pull/14673">https://github.com/numpy/numpy/pull/14673</a>. If we stop testing 3.5 in CI, don't release 3.5 wheels and remove the PyPI trove classifier for it (so installation tools may not install it anymore), then what's the point of saying we "don't drop it"? I'd rather keep it fully supported for one more month and release a couple of wheels, or just drop it completely. I don't have much of a preference which option is better, just would like to avoid half-dropping it.<br></div><div><br></div><div>Cheers,<br></div><div>Ralf<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite" id="gmail-m_-2189463113052914146gmail-m_1943618322760280026qt"><div dir="ltr"><div dir="ltr"></div></div></blockquote><div><br></div><div>The language in the NEP is:<br></div><div><br></div><div>"we recommend that
they support at least all minor versions of Python
introduced and released in the prior 42 months"<br></div><div><br></div><div>i.e., a lower bound for support, such that compatibility with more versions of Python is perfectly OK and, in the case of NumPy, probably encouraged.  The NEP is meant to lift the burden of very long support cycles from smaller projects.<br></div><div><br></div><div>Stéfan<br></div><div><br></div></div></blockquote><div><br></div><div>The 1.18.0rc1 is about one month out, so we should spend some effort on those PRs and issues with the 1.18 milestone. Dealing with issues and milestones, plus putting together the release notes, is the major pain point in making releases these days.</div><div><br></div><div>Chuck</div></div></div>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div>