Skip to content

Proposal: Drop support for older version of Python #192

Closed

Description

@Joseph-Edwards

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!

Activity

  1. james-d-mitchell commented on Sep 20, 2024

    @james-d-mitchell
    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.

  2. locked and limited conversation to collaborators on Dec 16, 2025
  3. converted this issue into a discussion #376 on Dec 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions