How do you retire a project's sys.version_info shims after raising its Python floor?

### Why this is a real task and not housekeeping A version shim is code with two lifetimes: the branch everyone runs, and the branch that only the oldest supported interpreter takes. Static analysis sees exactly one of them. A checker is told which version to analyse for and resolves `sys.version_info` comparisons itself, so the other branch is skipped entirely — no name resolution, no type errors, no unused-import warnings. Combine that with a CI matrix that quietly dropped the oldest version, and the fallback branch becomes code that nothing checks and nothing runs. A payment reconciliation job showed exactly this shape. It had carried, since its 3.9 days, a shim of the form `UTC = timezone.utc` in the branch for older runtimes and `from datetime import UTC` in the newer one — the `datetime.UTC` alias arrived in 3.11. A later refactor changed how timestamps were normalised, and only the live branch was updated; the fallback kept building naive datetimes. Nothing failed loudly. The symptom was a clock-skew artefact in the reconciliation output whenever the job ran on the old interpreter in one environment, at a 1,200-request-per-minute peak where a handful of mis-bucketed timestamps were easy to dismiss as noise. The shim was not the bug, but the shim is where the bug could hide. ### The order of operations Raise the floor first, in the packaging metadata: `requires-python` in `pyproject.toml`. That is the promise that changes, and it is what makes an installer resolve an older release for users still on the old interpreter instead of handing them a package that fails at import. Cut a release before deleting the shims, so there is a known-good last version for the runtimes you are dropping. Then sweep, mechanically. Grep for `sys.version_info` and read every hit. For each, delete the branch that can no longer be taken, delete the alias it created, and replace the conditional import with a direct one. Read the dead branch before deleting it — that is where drift lives, and the diff is the last chance anyone will look at it. Then the dependencies. A typing back-port distribution can usually be dropped once the floor covers every name in use, but only where nothing evaluates the name while the program runs. If it is still needed for a name added after your new floor, it stays; if it was gated by a `python_version` environment marker, the marker may now exclude every supported version and should go with it. Then the tooling. Trim the CI matrix to the versions you still support, and raise the version the type checker is told to target — otherwise it keeps analysing your code as if the old interpreter were still in play and will happily flag your new standard-library imports. ### What else falls out with the floor A floor bump often makes other scaffolding removable at the same time, and it is worth asking about each deliberately rather than sweeping. `from __future__ import annotations` was there so hints would not be evaluated on runtimes without lazy annotations; from 3.14 that behaviour is the default, but the two mechanisms are not identical for anything that inspects annotations, so removing the future import is a behaviour change to make on purpose and with tests, not as part of a shim sweep. `TYPE_CHECKING` guards, by contrast, are usually still worth keeping: they exist for import cost and cycles, not for version skew. ### How to tell whether it went well The checker runs clean against the new floor. No `sys.version_info` comparison remains that references a version at or below it. The dependency list has shrunk or is unchanged for a stated reason. The CI matrix and the checker target agree with `requires-python`. And the release notes say which interpreters were dropped, because for a library that is the user-visible part of the change — everything else is internal. ### The judgment behind the timing Raising a floor is not free: it strands users on older interpreters and forces their hand. The counterweight is the carrying cost of the shims themselves — branches nobody analyses, a matrix that grows with every supported version, and a vocabulary ceiling on the whole codebase. The usual trigger is the upstream end-of-life of the oldest version you support, which turns the question from a preference into a security argument.