Why Python Won’t Get a 4.0: The Calendar Versioning Plan Explained

Although many assume Python follows industry‑standard semantic versioning, the language has never officially adopted it, leading to dissatisfaction about backward compatibility expectations and lifecycle termination.

Python core maintainers are lobbying to change the version‑numbering scheme. Hugo van Kemenade, the upcoming release manager for Python 3.14 and 3.15, authored PEP 2026 – “Python Version‑Control Calendar” – to guide how all future versions will be numbered.

The proposal suggests a version format of 3.YY.micro , where:

3 is the major version and will always remain 3.

YY is the short year (e.g., 26 for 2026).

micro increments with each bug‑fix or security release.

Van Kemenade emphasizes that there will never be a Python 4; “Python 3” will become the enduring brand. Consequently, Python 3.15 is effectively 3.26, with “26” representing the release year 2026.

Python Lifecycle

Each Python version will be supported for five years, making the release schedule more transparent.

Since 2019, Python’s major releases have followed the schedule set by PEP 603, and the new calendar scheme better reflects development cadence.

Many mistakenly believe Python adheres to semantic versioning (MAJOR.MINOR.PATCH), but in practice many Python 3 releases break backward compatibility despite being under the 3.XX tree.

Van Kemenade presented the proposal at PyCon 2024 in Pittsburgh, arguing for a calendar‑friendly versioning (CalVer) that embeds the Gregorian year into the version number.

Canonical uses a similar CalVer scheme (YY.0M.micro), e.g., Ubuntu 24.02.

Future Python releases under the proposal are planned as:

3.15.0 in 2026 (displayed as 3.26)

3.16.0 in 2027 (3.27)

3.17.0 in 2028 (3.28)

3.18.0 in 2029 (3.29)

3.19.0 in 2030 (3.30)

Some observers on Slashdot warn that a two‑digit year scheme could cause ambiguity after the turn of the century, potentially complicating automated build systems.

Questions arise, such as whether Python v3.00 will follow Python v3.99 in the year 2100, prompting jokes about the Y2K bug.