When is raising a library's requires-python floor justified, and what evidence decides it?

### The question behind the question "When do we drop Python 3.10?" is really "what is the oldest interpreter still worth paying for?" It is a cost question with evidence on both sides, and the reason it is a lead's call rather than a maintainer's whim is that the cost is spread across users you cannot see. ### The evidence to gather **Upstream support.** CPython has shipped annually since PEP 602, and each minor line is supported for about five years — roughly two years of bugfix releases, then security-only fixes until end of life. That gives an unarguable outer boundary: 3.9 reached end of life in October 2025 and 3.10's security window closes around October 2026, so supporting either today means supporting an interpreter that will not receive even a security patch. It is the cleanest argument you have, because it is not about your preferences. **Install share.** Package indexes publish per-interpreter download telemetry, and it is the number that ends the argument. Telemetry is noisy — mirrors, CI runners and caches all inflate it — so read the trend rather than the level, and read it for *your* project rather than the ecosystem average, because a library used mostly inside long-lived enterprise images has a very different curve from a developer tool. **Your dependency floors.** You cannot support an interpreter that your own required dependencies have dropped; the resolver will simply fail to find versions of them, and the error will name them rather than you. Check the floors of everything you require before promising anything. **Your own cost.** Count the compatibility shims, the runtime guards, the conditional dependencies with markers, and the jobs in the matrix. A library rendering image thumbnails with a 340-case regression pack pays for that pack once per interpreter, on every push; and the oldest job is disproportionately the one that flakes — an occasional clock-skew artefact on the slowest runner — and disproportionately the one nobody wants to debug. That drag is genuine engineering time, and it should be stated in hours, not adjectives. **What the new floor buys.** Be concrete. If moving to 3.11 lets you delete an exception-aggregation shim in favour of native exception groups, or moving to 3.12 lets you use the type-parameter syntax and drop a compatibility import, say so. "We would like to use newer features" is not an argument; "this deletes 400 lines and two conditional dependencies" is. ### Why raising a floor is not abandonment The packaging metadata does the humane part for you. Once the new release declares a higher `requires-python`, an installer running on an older interpreter filters it out and resolves to your newest release that still allows it. Those users are not broken; they are frozen. That is the single most reassuring fact to bring to the discussion, and it is also why the floor must have been declared on the older releases too — the mechanism only works if the metadata was always there. What remains is a policy decision you own: does the last supporting line still receive security fixes, and for how long? For a widely-depended-on library the honest answers are usually "yes, for a stated window" or "no, and we say so plainly in the release notes." Silence is the bad option. ### How to execute it Raise the floor in a release whose version number signals a compatibility change under whatever versioning policy you publish, and announce it before it lands rather than in the changelog after. Land the deletions in the same change: shims, guards, conditional dependencies and matrix jobs should all disappear together, because a floor raised without the cleanup buys nothing and leaves the codebase claiming to support something it no longer tests. Add the new interpreter to the matrix before you remove the old one, so there is never a window where the top of the range is untested. ### The shape of the disagreement Expect the counter-argument to be about a specific dependent — a platform image, an enterprise environment, a downstream distribution frozen on an old interpreter. Take it seriously and make it concrete: who, how many, and for how long. Often the right answer is a stated support window on the old line rather than holding the whole project back, and occasionally it is that you are a leaf application rather than a library, in which case you are free to move immediately and the entire discussion is a five-minute one. ### The failure modes Moving too slowly accumulates shims that nobody understands and a matrix that costs more than the feature work. Moving too fast, without the metadata to catch old users, produces a wave of confusing installs on a release that cannot run. The discipline that avoids both is unremarkable: declare the floor from the first release, review it on a schedule tied to upstream end-of-life dates rather than to enthusiasm, and make the decision with numbers.