SPEC 0 — Minimum Supported Versions

shoyer · May 27, 2021, 4:52am

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:

github.com/numpy/numpy

ENH: Propose standard policy for dropping support of old Python versions

numpy:master ← tacaswell:cpython_support_nep

opened 01:54PM - 23 Jul 19 UTC

tacaswell

+314 -0

This NEP is a proposing a standard policy for the community to determine when we… age-out support for old versions of Python. This came out of in-person discussions at SciPy earlier in July and scattered discussion across github. This is being proposed by maintainers from Matplotlib, scikit-learn, IPython, Jupyter, yt, SciPy, NumPy, and scikit-image. TL;DR: We propose only supporting versions of Python initially released in the preceding 42 months of a major or minor release of any of our projects.

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.