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:
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.
Just pitching in that someone did a library to check packages dates: GitHub - hmaarrfk/nep29
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.
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