RFC: SPEC0 (was NEP 29) - Python and Numpy version support #803
Comments
|
I'm in favor of something a little slower, NEP + 1 year sounds good to me.
…On Mon, Sep 9, 2019 at 3:19 PM Chris Markiewicz ***@***.***> wrote:
Numpy has put out https://numpy.org/neps/nep-0029-deprecation_policy.html,
which proposes that scientific Python projects adopt the following approach
to supporting Python and Numpy:
- This project supports at least the minor versions of Python
initially released 42 months prior to a planned project release date.
- The project will always support at least the 2 latest minor versions
of Python.
- support minor versions of numpy initially released in the 24 months
prior to a planned project release date or the oldest version that supports
the minimum Python version (whichever is higher).
- The project will always support at least the 3 latest minor versions
of NumPy.
The minimum supported version of Python will be set to python_requires in
setup. All supported minor versions of Python will be in the test matrix
and have binary artifacts built for releases.
The project should adjust upward the minimum Python and NumPy version
support on every minor and major release, but never on a patch release.
Which works out to the following schedule:
On Jan 16, 2019 drop support for Numpy 1.12 (initially released on Jan 15, 2017)
On Mar 14, 2019 drop support for Python 3.5 (initially released on Sep 13, 2015)
On Jun 08, 2019 drop support for Numpy 1.13 (initially released on Jun 07, 2017)
On Jan 07, 2020 drop support for Numpy 1.14 (initially released on Jan 06, 2018)
On Jun 23, 2020 drop support for Python 3.6 (initially released on Dec 23, 2016)
On Jul 23, 2020 drop support for Numpy 1.15 (initially released on Jul 23, 2018)
On Jan 13, 2021 drop support for Numpy 1.16 (initially released on Jan 13, 2019)
On Jul 26, 2021 drop support for Numpy 1.17 (initially released on Jul 26, 2019)
On Dec 26, 2021 drop support for Python 3.7 (initially released on Jun 27, 2018)
This is a more rapid turnaround than we've been working with, as we've
only recently dropped support for numpy < 1.12. I want to get people's
thoughts on whether we should abide by this (bearing in mind that this only
affects major and minor releases; patch releases can continue supporting
older versions). I do think there's value in having a predictable schedule,
even if it's not identical. I see a couple options (and am open to others):
1. NEP 29 + 1 year, which will more closely match Python end-of-life
2. Python end-of-life + NEP 29 schedule for numpy
3. Continue as we are, ratcheting numpy when we really need to, but
not faster than NEP 29
At any rate, this is definitely something we should be aware of in terms
of how the overall ecosystem will interact with nibabel if we keep a slower
timeline.
Related: #734 <#734> #735
<#735>
@nipy/core <https://github.com/orgs/nipy/teams/core> @nipy/team-nibabel
<https://github.com/orgs/nipy/teams/team-nibabel>
cc the Gentoo ***@***.*** <https://github.com/TheChymera>), CentOS (
@sanjayankur31 <https://github.com/sanjayankur31>), and NixOS ***@***.***
<https://github.com/ashgillman>) packagers
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#803?email_source=notifications&email_token=AAAQQHA7IA3MALEK77VBLYTQIZLQVA5CNFSM4IU3256KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HKF73AQ>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAQQHBBIRDFGVHHXV3DYCLQIZLQVANCNFSM4IU3256A>
.
|
|
+1 for NEP +1 year. Thank you for this information. (@Garyfallidis, @arokem, What do you think?) |
|
Not getting a ton of feedback, but I'm happy to proceed on a NEP 29 + 1 year basis. That's very close to what we've been doing, and was where I was kind of inclined. We can revisit as needed. |
|
Sorry for the slow feedback. NixOS tends to move pretty fast, and locks with releases, so as long at the latest version is supported at any given time, no worries. |
|
No issues on Gentoo, the distribution is rolling release, so it should always pull in the newest versions of dependencies unless otherwise specified. Our packages check the test suites, so even if numpy/python get a newer version which breaks backwards compatibility, we'll be noticing it before it gets rolled out (and probably letting you know as well). |
1 task
effigies
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
NiBabel has adopted a NEP 29 + 1 year upstream support schedule, so there is a set of dates after which the next minor release will no longer support given versions of Python and numpy. Those dates and versions are as follows:
This table is to be updated with actual release numbers when determined, and new end-of-life dates as Python and numpy releases determine them.
Original post follows.
Numpy has put out https://numpy.org/neps/nep-0029-deprecation_policy.html, which proposes that scientific Python projects adopt the following approach to supporting Python and Numpy:
Which works out to the following schedule:
This is a more rapid turnaround than we've been working with, as we've only recently dropped support for numpy < 1.12. I want to get people's thoughts on whether we should abide by this (bearing in mind that this only affects major and minor releases; patch releases can continue supporting older versions). I do think there's value in having a predictable schedule, even if it's not identical. I see a few options (and am open to others):
At any rate, this is definitely something we should be aware of in terms of how the overall ecosystem will interact with nibabel if we keep a slower timeline.
Whatever we adopt, it will affect the whole nipy ecosystem, so if we do adhere to NEP 29, we may effectively force that schedule onto other nipy projects.
Related: #734 #735
@nipy/core @nipy/team-nibabel
cc the Gentoo (@TheChymera), CentOS (@sanjayankur31), and NixOS (@ashgillman) packagers
The text was updated successfully, but these errors were encountered: