Time to start NumPy 1.26 development?
Hi All, We plan to release NumPy 1.26 soon after the release of the Python 3.12.0rc1 release, which is currently scheduled for July 31, just a bit more than two weeks off. What I'd like to do is 1. Tag the commit after v1.25.1 -- f9e85438782cc5 -- as 'v1.26.0.dev0', marking it as the start of 1.26 development. 2. Backport the `meson.build` files from main. This is mostly automatic, but a few changes need to be made. 3. Backport the files for spin builds. 4. Begin testing the Python 3.12 betas 5. Update OpenBLAS when we are happy with it. 6. Wait for SIMD support? I'm wondering if we can split the builds, using distutils for Python 3.9-3.11 and meson only for 3.12, or if that is even worth the trouble. Thoughts? Chuck
On Fri, Jul 14, 2023 at 10:59 PM Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
We plan to release NumPy 1.26 soon after the release of the Python 3.12.0rc1 release, which is currently scheduled for July 31, just a bit more than two weeks off. What I'd like to do is
Thanks for getting the ball rolling here Chuck. The overall plan sounds good to me. A few suggestions:
1. Tag the commit after v1.25.1 -- f9e85438782cc5 -- as 'v1.26.0.dev0', marking it as the start of 1.26 development.
I'd branch from the latest commit on `maintenance/1.25.x` instead, there
are relevant recent backports.
1. Backport the `meson.build` files from main. This is mostly automatic, but a few changes need to be made. 2. Backport the files for spin builds.
There will be some other things to backport perhaps. Although I see you've
already some of that (e.g., the clang-cl fixes) for 1.25.2, so not quite sure what is left. Aside from all the CI job changes to Meson of course.
1. Begin testing the Python 3.12 betas 2. Update OpenBLAS when we are happy with it.
I'll note that it this point we should make a 1.26.0b1 release. We don't
need SIMD support to unblock downstream libraries from building wheels. This can be done shortly after the Python 3.12.0rc1 release.
1. Wait for SIMD support?
Yes, that should land in `main` first and then be backported too. Once
that is done, we should cut a 3.12.0rc1 - timeline is the sooner the better, but by mid September so we have at least two weeks before making a final release.
I'm wondering if we can split the builds, using distutils for Python 3.9-3.11 and meson only for 3.12, or if that is even worth the trouble.
It's not really possible, since one must choose a single default as the build backend hook in pyproject.toml. I also don't think it's necessary or a good idea, because it would make it more difficult to figure out what's a Python 3.12 issue vs. what's due to our build system change. Other thought: do we want to backport some deprecations for functions/objects that will be removed in 2.0? It's not necessary, but it could be helpful. Cheers, Ralf
Thoughts?
Chuck _______________________________________________ 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: ralf.gommers@googlemail.com
participants (2)
-
Charles R Harris
-
Ralf Gommers