Reducing supported Python Versions

[MicahGale]

Background

I recently came across NEP 29.

NEP 29

This NEP was meant to set the version support guidelines for NumPy, SciPy, matplotlib, and the majority of the scientific python ecosystem in 2019. The policy is well summarized by their policy of:

When a project releases a new major or minor version, we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months from the anticipated release date with a minimum of 2 minor versions of Python, and all minor versions of NumPy released in the prior 24 months from the anticipated release date with a minimum of 3 minor versions of NumPy.

SPEC 0

This is a follow-up to NEP 29, and is from the Scientific Python Ecosystem. They are ever so slightly more restrictive:

Specifically, we recommend that:

• Support for Python versions be dropped 3 years after their initial release.
• Support for core package dependencies be dropped 2 years after their initial release.

Bonus points: Spec 0 comes with a badge!

Status Quo

Currently MontePy's support policy is to support (namely test against) all minor versions of Python that are receiving security updates. This means as of may 2025 that Python 3.9 - 3.13 are supported. The last version of NumPy to support Py 3.9 was numpy 1.25, which according to NEP 29 should lose support next month.

While there is currently no support crisis right now, supporting Python 3.9 is rather limiting (see #588).

What this would mean to adopt NEP 29.

1. Adopt NEP 29 language. The NEP provides the following template language:

This project supports:

• All minor versions of Python released 42 months prior to the project, and at minimum the two latest minor versions.
• All minor versions of numpy released in the 24 months prior to the project, and at minimum the last three minor versions.
• In setup.py, the python_requires variable should be set to the minimum supported version of Python. All supported minor versions of Python should be in the test matrix and have binary artifacts built for the release.

Minimum Python and NumPy version support should be adjusted upward on every major and minor release, but never on a patch release.

2. Current support window covered by this policy would cover:
   1. 42 months prior to today is November 2021, and covers Python 3.10 - 3.13
   2. 24 months prior to today is May 2023, which covers Numpy 1.25+, and 2.0+

What this would mean to adopt NEP 29.

1. Language from NEP 29 is easy to tweak for SPEC 0

2. SPEC 0 provides a drop schedule that currently extends through 2027.

3. Current support window covered by this policy would cover:

   1. 36 months prior to today is May 2022, and covers Python 3.11 - 3.13
   2. 24 months prior to today is May 2023, which covers Numpy 1.25+, and 2.0+ (though numpy 1.25 is about to EOL in June)

Elephant in the room: SLY

Sly was last released on PyPI in 2022, and is therefore outside of the 24 month core package window.
We have known for awhile this is a bit of a dependency liability (#432). Though it is not creating new features, etc. that we have to be worried about supporting on the other hand.

For the time being I do not expect python 3 to break backwards compatibility in a way that would break sly.
If needed: we can legally vendor SLY and create a patched version of SLY that is supported by the latest versions of python.

Though long term #432 will need to be implemented to have better long term support.

Note

GitHub does not support ranked choice voting. However they are listed in a way that they are a superset of all options below them. So please vote for the most restrictive version you support.