| title | SPEC 0 — Minimum Supported Dependencies | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| number | 0 | ||||||||||
| date | 2020-12-17 | ||||||||||
| author |
|
||||||||||
| endorsed-by |
|
This SPEC recommends that all projects across the Scientific Python ecosystem adopt a common time-based policy for dropping dependencies. From the perspective of this SPEC, the dependencies in question are core packages as well as older Python versions.
All versions refer to feature releases (i.e., Python 3.8.0, NumPy 1.19.0; not Python 3.8.1, NumPy 1.19.2).
Specifically, we recommend that:
- Support for a given version of Python to be dropped 2 years after the next version of Python is released.
- Support for a given version of a Python package be dropped 1.5 years after the next version of that package is released.
{{< admonition note >}} Packages may or may not provide bug fix releases during the full support period. Therefore, projects may occasionally want to drop support for package dependencies earlier than recommended by this SPEC. For instance, if a newer minimum version of a package is needed by a project due to a critical bug fix, which is not backported to older versions. {{< /admonition >}}
Core project endorsing this SPEC means that those projects encourage all projects across the Scientific Python ecosystem to limit how long they support older Python versions and older dependency versions. A core project endorsing this SPEC does not imply that that project will provide bug-fix releases for two full years after a release.
Projects can highlight their adoption of this SPEC by including a SPEC badge. {{< spec_badge number="0" title="Minimum Supported Dependencies" >}} To indicate adoption of multiple SPECS with one badge, see this.
Limiting the scope of supported dependencies is an effective way for packages to limit maintenance burden. Combinations of packages need to be tested, which impacts also on continuous integration times and infrastructure upkeep. Code itself also becomes more complicated when it has to be aware of various combinations of configurations.
Adoption of this SPEC will ensure a consistent support policy across packages, and reduce the need for individual projects to divise similar policies.
Ultimately, reduced maintenance burden frees up developer time, which translates into more features, bugfixes, and optimizations for users.
In the past, longer support cycles were common. There were several reasons for this, including the Python 2 / 3 transition, difficulties installing packages, and users needing to use old, operating-system provided versions of Python. The situation has since improved due to improved installations via binary wheels, virtual environments becoming commonplace, and support for Python 2 being dropped.
{{< include-raw "chart.md" >}}
Below is an auto generated schedule with recommended dates for dropping support. We suggest that the next release in a given quarter is considered as the one removing support for a given item.
You may want to delay the removal of support of an older Python version until your package fully works on the newly released Python, thus keeping the number of supported minor versions of Python the same for your package.
{{< include-md "schedule.md" >}}
-
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.
-
Code to generate support and drop schedule tables:
{{< include-code "SPEC0_versions.py" "python" >}}