On Fri, Jul 14, 2023 at 10:59 PM Charles R Harris <charlesr.har...@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-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: ralf.gomm...@googlemail.com >
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com