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

Reply via email to