Best Practices: Deprecation policy for EOL Python versions

[ulgens]

I'm coming from https://github.com/orgs/django-commons/discussions/89#discussioncomment-11099217 and I'm not sure what is the best format so feel free to share recommendations or edit.

Idea

When a Python version sees EOL, support for the given Python version should be removed from all packages either immediately or after a selected short time period: https://devguide.python.org/versions/#python-release-cycle

An automated rule/workflow that removes EOL Python versions from all packages in the organization may be the end goal there. If a package doesn't want to follow the common deprecation policy, exceptions can be made.

• "We don't want to update our dependencies because people using us doesn't update theirs" should not be a valid excuse to get exempt from the policy. Python EOL dates are announced multiple years in advance.
• A debugging tool or other things that helps to move away from the EOL - outdated versions can be the perfect exception.

Benefits

• I think it's obvious but nobody should spend their energy to support EOL dependencies. Instead, we can recommend people to update their Python version, I believe it will be more beneficial for all parties.
• It's hard to debug old things. In Python's scope, being EOL is a good indicator of something being old. Debugging a problem with a supported version of Python is easier than an EOL version.
• It helps to keep things modern.

Rules

1. Min Python requirement shouldn't be in the EOL state.
2. Min Python requirement doesn't have to be the oldest supported version. Projects can define a higher lower bound.
3. The project's linter shouldn't include anything older than the min Python requirement.
4. The project's Github Actions shouldn't include anything older than the min Python requirement.
5. The project's trove classifiers shouldn't include anything older than the min Python requirement.
6. The project's code shouldn't use features from anything older than the min Python requirement.
7. The project's code should be optimized and modernized for the min Python requirement.

Automation

I'll make some assumptions and list a couple of prerequisites that we didn't discuss before.

• All projects should include [pyupgrade](https://github.com/asottile/pyupgrade)
  • It is the perfect tool for the job, but is there any alternative?
• pyupgrade should be configured with target-version = py<min_supported_version>
• pyupgrade should be applied automatically in the development environment and GitHub Actions.
  • My personal preference for automatic quality checks in a development environment is pre-commit, and then I use it with a thin wrapper in GitHub Actions. I guess tox is the better choice for package development, but I think the same can be achieved with tox.

These steps will only handle rules 6 and 7. Please share your recommendations for the rest.

---

Updates

Oct 31, 2024

• Grammar & typo improvements
• Rewrote the idea part.
• Update the title for clarity

[cunla]

I have experienced some pushback when not supporting EOL python versions (here is a recent example in fakeredis).

Is removing support for an EOL python version considered a breaking change (i.e. major version)?

[browniebroke]

In this case, why can't they stay on the previous version that does support 3.7? Is it because it's in a test matrix of downstream open source project?

There are exceptions, especially for testing libraries, but I feel like it's less the case for Django packages, which are typically installed in an final application.

If the project is OK with staying on an older Python version, why do they want to stay on the latest version of other libraries? Why not stay on the latest version that supports your current python version? They won't be able to use the latest Django, for example.

[Stormheg]

I mostly echo what Bruno said. Why are they on such an old Python version? If they really need to run old software, why can't they stay on the previous version of the library that did have support for old Pythons?

Eventually supporting old versions is going to hold you back. Python is getting better every year with new language features and improvements to the standard library. You should want to make use of that.

Supporting end-of-life Pythons sounds like an anti-pattern to me. In your example you have been accommodating @cunla - I don't think I would have done the same. I feel like it muddies the waters: you are not going to support 3.7 forever, right? When would be the time to drop it?

[ryancheley]

Could we recommend a Deprecation Policy as a best practice.

I can see situations where some maintainers may have a policy which indicates only current versions of Python are supported, while another could have a policy which indicates they support 2 EOL versions of Python (or something similar) are supported 🤔

[tim-schilling]

I think this is what we should strive for. I see a future in which there are too many projects to maintain a hard line stance. I think being explicit in what we think is best, but flexible in what people do is ideal.

What I'd like to combine this with is a GitHub action that the Commons maintains and others can use out of the box to test their application. That way they have the option of using what we think is best without having to do any work to meet that standard.

[bckohan]

The only hard and fast Python version rule I'm really comfortable with is in the opposite direction. "Thou shalt support the latest Python/Django" - but even this is probably best implemented as a carrot rather than a stick (some kind of badge for long-term compliance).

I don't have a strong affirmative case for not removing EOL versions from the test matrix. In my own experience I leave it in there until something breaks and if its EOL I kick it out, update the dependency range and issue a new release. I'm not really doing any extra work to support EOL versions, I'm just not being proactive about removing them - which I think is fine. The strongest case I could make for being proactive is reducing the burden on the django-commons actions quota haha (not really sure what the deal is with that?).

It's also important to note that in a lot of downstream applications the person writing the code is not always in control of the production environment. I have a few times intentionally supported EOL pythons in my open source packages for this reason. I've wanted to add new feature to the code, but the lethargy of the IT apparatus was a real hurdle. And if the point of all this is to make the experience of using Django better, I'm way more interested in the experience of that dev caught between a lethargic IT department and the future of their code base than I am about incentivizing IT to do their jobs. This kind of dynamic is hugely present in government (because they tend to operate like its 2005) and I also think "the government" is a massively untapped resource for DSF funding - so it may pay to keep those downtrodden devs happy.

[bckohan]

I am strongly supportive of something like "All major dependency versions must be in your CI matrix" - but this might also be murder on the actions quota... am I too concerned about the actions quota?? lol

[bckohan]

All of this is also complicated by a large variance in how folks specify dependency ranges. For example, I see this a lot: django>=4.2. I always put a maximum on my upstreams because I don't want anyone to try to run it against a new major version I haven't tested against and then come complaining when it breaks. There's a tension here though - a lot of packages aren't all that complicated and specifying that major range means they'll have to do more busy work to keep up with the updates.

To stay in compliance with the suggestion in my last comment you can't really have open ended version specifiers. I think its a tad unreasonable to ask folks to be this fastidious without some kind of help. Most of the work here is tending to the CI and I'm convinced it wouldn't be that hard to automate this through github actions. I'm trying to do this for my own projects as time permits.

[tim-schilling]

The strongest case I could make for being proactive is reducing the burden on the django-commons actions quota haha

I think another way to think of this is reducing our environmental footprint. Do you need to test against EOL python versions on every change, or could it be reduced to once a week? Especially if the likely response is to remove the version rather than change the library to accommodate it?

Regarding your GHA CI idea, I had something similar come to mind here: https://github.com/orgs/django-commons/discussions/94#discussioncomment-11172701