The Python release cycle is the calendar on which the Python core team publishes new feature versions of CPython, maintains them and retires them. Since Python 3.9 a feature version has been released every twelve months, in October.[2] Each version is supported for five years in two phases: bugfix, then security.[1] The licence does not change between versions: Python software and documentation are licensed under the PSF License Version 2.[5] For software asset management (SAM), Python versions are therefore tracked for support and security exposure, not for entitlement. Catalog proof: Python feature releases ship annually in October; Each Python version is supported for five years.
Release calendar
PEP 602 sets about 17 months of development for each feature version (3.X.0). The first five months overlap with the previous version’s beta and release-candidate stages. Seven months of alpha releases follow, then three months of four beta releases (no new features), and two months of release candidates before the final release.[2] Feature work on the next version starts when the current one reaches beta 1, which gives a twelve-month gap between feature versions.[2] The Developer’s Guide calls these phases feature and prerelease, followed by bugfix, security and end-of-life.[1]
Support phases
| Phase | What is accepted | Releases |
|---|---|---|
| feature | New features, bug fixes, security fixes, before the first beta[1] | Alphas |
| prerelease | Feature fixes, bug fixes and security fixes after the first beta; no new features[1] | Betas and release candidates |
| bugfix | Bug fixes and security fixes; also called maintenance mode or stable release[1] | New binaries roughly every two months[1] |
| security | Only security fixes; starts after two years (18 months for versions before 3.13)[1] | Source-only, as needed, no binaries[1][2] |
| end-of-life | Nothing; support ends five years after release and the release cycle is frozen[1] | None |
Full support lasts two years from Python 3.13. Versions 3.9 to 3.12 follow a calendar of one and a half years of full support and three and a half years of security fixes.[2] A security branch accepts only fixes for issues exploitable by attackers, such as crashes and privilege escalation. Its releases are source-only and are made only when security fixes have been applied.[3] At end of life the branch is removed from the repository, and its final state is kept as a tag.[3] Catalog proof: Security-phase Python releases are source only.
Version status
As listed on 2026-09-27:[1]
| Branch | Status | First release | End of life |
|---|---|---|---|
| main (future 3.16) | feature | 2027-10-06 (scheduled) | 2032-10 |
| 3.15 | prerelease | 2026-10-01 (scheduled) | 2031-10 |
| 3.14 | bugfix | 2025-10-07 | 2030-10 |
| 3.13 | bugfix | 2024-10-07 | 2029-10 |
| 3.12 | security | 2023-10-02 | 2028-10 |
| 3.11 | security | 2022-10-24 | 2027-10 |
| 3.10 | security | 2021-10-04 | 2026-10 |
| 3.9 | end-of-life | 2020-10-05 | 2025-10-31 |
| 3.8 | end-of-life | 2019-10-14 | 2024-10-07 |
| 3.7 | end-of-life | 2018-06-27 | 2023-06-27 |
| 3.6 | end-of-life | 2016-12-23 | 2021-12-23 |
| 2.7 | end-of-life | 2010-07-03 | 2020-01-01 |
Python.org lists 3.14.7 as released on 2026-08-05, the latest 3.14 maintenance release at retrieval.[4] Micro releases within a maintenance branch must not break compatibility with each other.[3]
Software asset management practice
The points below apply the cited schedule to SAM work. They are commentary.
- Normalize to the feature version. End of life is set per feature version (3.x), not per micro release, so inventory records should keep the 3.x value alongside the full version string.[1]
- Flag the security phase separately. A runtime in the security phase is still supported, but no new official binaries are published for it.[1] Fleets installed from python.org Windows or macOS installers cannot be patched with a new official installer once their version leaves bugfix. They need a source build, a redistributor’s build, or an upgrade.
- Plan an annual upgrade. With one feature version every October and five years of support, about five 3.x versions are supported at any time, and one leaves support each October.[2][1]
- Watch scheduled dates. Dates shown in italics on the status page are scheduled and can be adjusted by release managers. Re-read the page before committing retirement dates.[1]
- Redistributors’ lifecycles differ. Operating-system and platform vendors that ship their own Python builds set their own support periods. The PSF dates describe upstream CPython only.
Out of scope
- Support lifecycles of Python runtimes bundled by operating-system vendors, cloud platforms or commercial distributors.
- Lifecycles of PyPI packages, which each project sets for itself.
- Pre-3.x release history beyond Python 2.7, and alternative implementations.