A Runtime Upgrade Needs a Workload Receipt
Python’s 3.10 branch ended upstream security maintenance with the 3.10.22 release, dated 1 October 2026. It supplies source archives, not installers; the project’s final platform installers for that branch came with 3.10.11. Applications may still run, but further upstream fixes are not forthcoming. Vendor-maintained builds require separate supplier evidence.
The practical task is to connect each deployed service to an accountable migration decision. A repository’s compatibility declaration is not an inventory of what production starts. An administrator’s newer local interpreter does not prove that a background worker, scheduled task or container was rebuilt.
The record changed
The 12:06 UTC revision of PEP 619 on 1 October 2026 preceded this article’s original publication. It listed that day’s final release but contained a 2025 lifespan typo. The correction followed at 17:46:42 UTC that same day. The earlier article also recorded the developer version table as still showing 3.10 in security maintenance; that historical rendering has not been independently recovered. Both current pages mark the branch as unsupported upstream.
As rechecked on 21 October 2026, the table lists 3.15 and 3.14 in bugfix maintenance, and 3.13, 3.12 and 3.11 in security maintenance. This is a status snapshot, not a universal upgrade target. Choose a branch supported by the application and its suppliers, with a maintenance horizon suited to that service.
Recreate the runtime and its dependencies
The venv guide says an environment uses a base interpreter and should be recreated rather than moved or copied. Record that base and the installed dependencies before rehearsal.
The Packaging User Guide uses Requires-Python to describe which interpreter releases a package accepts. Its distribution workflow explains that compiled extension wheels are tied to a particular interpreter, operating system and CPU architecture, with a possible source-build fallback. An import test alone will not establish that a deployment image has the necessary wheels and native libraries.
Make the cutover evidence visible
BlackTree’s operational checklist is a record of decisions, not a claim that every application needs the same migration procedure.
- Name the service owner and capture the executable path and package or image that the workload starts.
- Agree a target with the supplier, then rebuild a representative deployment and run functional, security and performance checks.
- Record the release artefact, deployment window, rollback route and criteria for stopping the change.
- After cutover, verify every worker and scheduled job, not just the front-end process. Keep the results with the service record.
Sources
- Release announcement.
- Upstream branch calendar.
- Developer support table, status table checked 21 October 2026.
- Environment guide, checked 21 October 2026.
- Packaging metadata, checked 21 October 2026.
- Distribution workflow, last updated 12 October 2026.
