https://github.com/numpy/numpy/pull/21601 has been merged, but we should make sure everyone is on board with the updated wording. The intent was to resolve the discrepancy I think Aaron is referring to (the text spoke of the 18mo release cycle in present tense) and to justify sticking with 42months despite the upstream change. I think it is good for the overall community if we have a (mostly) unified position on this, but if projects are going to disregard NEP 29 I am personally happy for them to run faster :) Tom On Thu, May 26, 2022 at 7:08 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Thu, May 26, 2022 at 4:41 AM Aaron Meurer <asmeurer@gmail.com> wrote:
I have seen problems popping up already in a few places with latest numpy not supported what is still the most commonly used Python version (don't have links, sorry - but they were real packaging-related issues). So I don't think it makes sense to shorten the time window. I also don't think there's a need to drop one version that's urgent - it's some effort and CI time, but the balance is decent right now.
It's hard to say the balance is decent right now if the faster cadence isn't even in full effect yet (as I noted in my original email).
Generally I would say that dropping support only means that users of older versions would simply need to use an older version of the library.
That is not the full story unfortunately. The Python packaging tooling (Pip, Poetry et al) is imperfect, so if other packages depend on NumPy and then at install time a tool figures out that latest NumPy cannot be used, or somewhere there's an upper bound in the version constraints explicitly, some things tend to go wrong.
There was a lot of discussion around how big the window should be with 42mo being about in the middle of what people advocated for. I am aware of institutions that are on an every-other Python upgrade pattern (py37 -> py39 -> (expected) py311) so always having at least 3 Pythons in the window is important. Based on what we have seen so far, I still think 42mo is a good choice, but do not think we have seen it in operations long enough to draw any conclusions (the downside of year-scale planning is you need to wait years to see if it worked out like you expected!) and hence do not think we should make any changes to the time window for another few years. That said, I am currently sympathetic to making the window longer and against making it shorter.
The reason I brought this up is because we were looking at whether it makes sense to use NEP 29 for SymPy. Obviously we aren't bound to using it, but given this apparent discrepancy in the text (which still exists),
What discrepancy?
Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: tcaswell@gmail.com
-- Thomas Caswell tcaswell@gmail.com