I maintain a Python CLI and development tool for Polylith-style architectures, mainly used with microservices in monorepos. A small number of users still run Python 3.8, and some use Python 3.9.
Dropping support would make maintenance easier because I could adopt PEP 621 internally and update some dependencies. There is no urgent need, but I am considering doing it during 2026. The project follows semantic versioning, so I am unsure whether removing support for these already-end-of-life Python versions should count as a breaking change and require a major version bump.
A major release might cause teams to overlook future updates if they pin to the current major version. On the other hand, making the change in a minor release could appear to break installations for users who still run Python 3.8 or 3.9. The tool is primarily installed in development environments and CI, rather than being part of the deployed application itself.
What is the usual and least disruptive way to handle this? Should I use a major release, a minor release with a deprecation period, or simply declare the newer Python requirement and let package managers resolve the last compatible version?
4 Answers
There can still be operational edge cases. Some Linux distributions ship an older system Python, and people sometimes install command-line tools outside a virtual environment. That makes a support drop potentially inconvenient, particularly in CI or system-level scripts. Since this tool is mainly a development and CI dependency, the impact is probably limited, but announcing the timeline well ahead of time is worthwhile.
Treat this as a support-policy change rather than an API-breaking change. You can state that support ends when the corresponding Python version reaches end of life, or follow a predictable annual schedule. As long as `requires-python` is correct, users on older interpreters are protected from installing a release they cannot use, while users on supported interpreters can continue receiving updates.
Declare the supported range explicitly with `requires-python` in the package metadata. Installers such as pip, uv, and Poetry use that information when resolving versions, so a Python 3.8 or 3.9 environment should receive the newest release that still supports it instead of an incompatible release. Users who manually force or explicitly upgrade to an incompatible version may see an error, but normal dependency resolution should remain safe.
Dropping end-of-life Python versions generally does not justify a major version bump by itself. A minor release is reasonable, especially if you announce the change and include deprecation warnings in earlier releases. Document the final supported release for 3.8 and 3.9, then make the new requirement explicit in the release notes and package metadata.
That was the scenario I had overlooked. I was thinking mainly about manually changing a dependency version in a project file, but existing installations should normally resolve the latest compatible release.