You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
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!
The text was updated successfully, but these errors were encountered:
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.
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:
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!
The text was updated successfully, but these errors were encountered: