Recommends a drop schedule for old versions of Python, NumPy, SciPy, and Matplotlib.
The link to the rendered document is currently broken.
This is a superset of NEP 29, so let’s link that: NEP 29 — Recommend Python and NumPy version support as a community policy standard — NumPy Enhancement Proposals
The link will work once we publish the draft website. Until then, you can find the draft here:
https://draft.scientific-python.org/specs/spec-0000/
The first item in the Notes section links to NEP 29:
This document builds on NEP 29, which describes several alternatives including ad hoc version support, all CPython supported versions, default version on Linux distribution, N minor versions of Python, and time window from the X.Y.1 Python release.
Hi,
Just pitching in that someone did a library to check packages dates: GitHub - hmaarrfk/nep29
2 Likes
Thanks for writing this up! This is a great proposal for starting the SPEC process 
I wanted to (re)surface a concern that came up when we tried to generalize the NEP-29 policy for other dependencies in Xarray:
The basic problem is that “Support to be dropped 2 years after their initial release” fails in when projects fail to make regular releases (e.g., at least every 6 months). This hopefully won’t happen again for core scientific Python projects but has been an issue in the past. (It would also make the policy generalize better to non-core projects, which tend to have more irregular releases.)
For example, matplotlib 1.5 was released in October 2015, but 2.0 wasn’t released until January 2017. If we followed the “Support for two years from release” model, then downstream packages could have dropped support for matplotlib 1.5 in October 2017 – only 9 months after matplotlib 1.5 became out-dated and well before matplotlib 2.0 was broadly distributed.
The model that I would like to see instead is along the lines of “Support to be dropped X months after the release becomes out-dated.” In particular, I would propose:
- Support for a given version of Python to be dropped 24 months after a newer major version of Python is available.
- Support for a given version of other core packages to be dropped 18 months after a newer major version of the dependency is available.
In practice this should work out to the same support window as 3/2 years, assuming 12 month release cycles for Python and 6 month release cycles for other core projects.
From a user perspective, I think “drop after outdated” is also easier to work with, because it aligns better with regular time-based processes for managing dependencies. For example, if I setup a new Python environment every 18 months, I know my users will be able to use the bundled version of all core dependencies until the next time I update my environment.
In contrast, the existing NEP 29 / SPEC 0 is an upper bound on how long your environment will work – my environment will almost certainly break in 24 months – but who knows exactly when.
4 Likes
Just wanted to pitch in that scikit-learn supports the oldest version of scipy, numpy, matplotlib etc supported by ubuntu LTS. This is the best reference I can find: [RFC] Minimal scipy version for 1.0 (or 0.26) release · Issue #19705 · scikit-learn/scikit-learn · GitHub
@shoyer I was looking at the xarray PR you mentioned, and there it is worded as to support “the latest minor (X.Y) version from N months prior” (so the most recent minor version (X.Y) available N months ago).
I am struggling to decide whether those two ways to define it are actually the same in practice 
(I think so?)
@jorisvandenbossche Yes, this is intended to mean the same thing! I don’t know which is clearer
Hello,
I have been trying to follow the SPEC-000 requirements a bit more lately, and I find the initiative really good. It shares a lot of traits with the VFX Reference Platform we use in the Movie and Game (to some degree) industries.
Something we do at WetaFX though to make it easier for dependents to be sure that they select the correct dependencies is that we have packages that pull down the correct versions as a function of the platform year.
In a quite similar way, I would like to suggest that a Scientific Python package is created on Pypi. This package would requires and specify the mandated current minimum versions which would allow someone to grab the appropriate stack in one go instead of requiring the dependencies one-by-one.
Thoughts?
Cheers,
Thomas
Hello,
The recommended versions are currently out-of-date for some of the packages, e.g. Numpy, Matplotlib.
Would it be please possible to update the timeline?
Cheers,
Thomas
1 Like
I will update it later today or tomorrow (of course, coauthors and PRs are more than welcome!).
1 Like
I haven’t had time to update things, so I created an issue so I don’t loose track of this:
For requests like this, I would recommend opening issues or making PRs to the repo directly. This is mainly a comment so that issues for the repo end up on the repo and not here.
1 Like
Thank you @jarrodmillman, that makes sense!
1 Like