New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MAINT: set Python version for 1.21.x to <3.11
#19497
Conversation
Note that SciPy has a more elaborate method here, using `IS_RELEASE_BRANCH`. Given that we're switching away from `setup.py` at some point and the ship kind of has sailed for 1.21.x already, I don't want to replicate that logic here.
I plan on adding Python 3.10 to a future 1.21 release. |
This constraint is just meant to match whatever the release notes say. Which admittedly is a bit ambiguous right now:
Did you mean for |
I'll release 1.21.1 this weekend. Python 3.10 is scheduled for 10/04 + 1-3 weeks to be available on azure, so probably will be supported in NumPy 1.21.4-5. Given the offset in Python and NumPy release cycles, I expect that sort of timing will persist. I like to keep the Python support up to date in a given release cycle because I suspect that distros like fedora will update both python and numpy in their spring releases. |
Okay, then I think this is fine to merge. And it can be bumped to |
I'm not sure. It should be, but it depends on the version comparison function used. Let's see what CI says. |
Close/reopen to see if 3.10.0b3 tests run. That test was added after this PR was made. |
The 3.10.0b3 test runs. Thinking about it, how about using |
All right, since we have CI for 3.10 we may as well lie a little bit and let people build these releases from source. Making it |
Let's only add the trove classifier ( |
<3.11
Thanks Ralf. |
Note that SciPy has a more elaborate method here, using
IS_RELEASE_BRANCH
. Given that we're switching away fromsetup.py
at some point and the ship kind of has sailed for 1.21.x already, I don't want to replicate that logic here.