Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Drop support for older version of Python #192

Open
Joseph-Edwards opened this issue Sep 19, 2024 · 1 comment
Open

Proposal: Drop support for older version of Python #192

Joseph-Edwards opened this issue Sep 19, 2024 · 1 comment

Comments

@Joseph-Edwards
Copy link
Collaborator

Presently, we try and provide support for any released version of Python that is not end-of-life. At the time of writing, this is versions 3.8–3.12. I was looking into how NumPy do things and came across the Scientific Python Ecosystem Coordination (SPEC) project. They have a list of documents that "provide recommendations for projects in the scientific Python ecosystem".

SPEC 0 (Minimum Supported Dependencies) says:

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

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

I propose that, like iPython, Matplotlib, NetworkX, NumPy, scikit-image, SciPy and more, we adopt this SPEC. It would allow us to use more up-to-date Python features, and give us a more objective perspective on which dependency-related issues are worth resolving.

Under this SPEC, we would support Python >= 3.10 (dropping support for 3.10 in October 2024) and NumPy >= 1.24.

I'm happy to hear any thoughts on this!

@james-d-mitchell
Copy link
Member

For my taste, this is slightly too aggressive. I think I'd prefer to support the oldest "reasonable" (by some definition) version of python that we can. One major difference between libsemigroups_pybind11 and the other projects you listed is their age. If someone has an old version of python they can use an old version of numpy, this isn't true for libsemigroups_pybind11 because it didn't exist until relatively recently.

I'd be happy to move to the model you suggest when, for example, there is a version of the package that can be used with python 3.9 that has been released, and python 3.9 (or whatever) reaches its end of life. Let's leave this open as a reminder about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants