-
Notifications
You must be signed in to change notification settings - Fork 248
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
Adopt NEP 29 #788
Comments
In principle having a common policy for supported package versions is a very good idea. However, my feeling is that having a support window of 2 years might be a bit tight for Neo since I would expect it to be used in (laboratory/experimental) environments that also need to follow a number of additional constraints. In this case following the drop recommendations above might lead to package conflicts and in the end to Neo not being as easily usable as we want it to be. |
I don't have strong opinion on this. We have to take in account that in small lab, there are small computing cluster with not very up to date OS. |
On reflection, I agree that a 24 month window is rather short for scientific projects. On the other hand, it would be nice to have some clear guidelines, both for Neo developers and for downstream projects. NiBabel has gone for NEP 29 + 1 year (nipy/nibabel#803) Currently, Neo claims to support Python >= 3.5 and NumPy >= 1.10, however the CI tests only test Python 3.5 and 3.6, and always install whatever NumPy pip gives, normally the most recent. Adopting NEP 29 + 1 year would give:
This seems more reasonable. It means we should bump the minimum version of Python to 3.6, and of NumPy to 1.13. On the other hand, pypistats gives the usage for the last month as:
so one in six Neo downloads is still for Python 3.5. |
Principle of NEP + 1 year accepted during meeting on 07/09/2020 |
https://numpy.org/neps/nep-0029-deprecation_policy.html
This is a recommendation that all projects across the Scientific Python ecosystem adopt a common “time window-based” policy for support of Python and NumPy versions.
This means, for example:
On next release, drop support for Python 3.5 (initially released on Sep 13, 2015)
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)
What do you think? This could reduce the development burden by reducing the number of older versions we support. On the other hand, we would have to be more proactive about adding new versions to the CI test matrix.
The text was updated successfully, but these errors were encountered: