matthew-brett
commented
5 years ago 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 notifications@github.com 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):
- NEP 29 + 1 year, which will more closely match Python end-of-life
- Python end-of-life + NEP 29 schedule for numpy
- 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 https://github.com/nipy/nibabel/issues/734 #735 https://github.com/nipy/nibabel/issues/735
@nipy/core https://github.com/orgs/nipy/teams/core @nipy/team-nibabel https://github.com/orgs/nipy/teams/team-nibabel
cc the Gentoo (@TheChymera https://github.com/TheChymera), CentOS ( @sanjayankur31 https://github.com/sanjayankur31), and NixOS (@ashgillman 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 https://github.com/nipy/nibabel/issues/803?email_source=notifications&email_token=AAAQQHA7IA3MALEK77VBLYTQIZLQVA5CNFSM4IU3256KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HKF73AQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAQQHBBIRDFGVHHXV3DYCLQIZLQVANCNFSM4IU3256A .
skoudoro
effigies
ashgillman
TheChymera
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):
1) Adopt NEP 29 2) NEP 29 + 1 year, which will more closely match Python end-of-life 3) Python end-of-life + NEP 29 schedule for numpy 4) 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.
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