A Python core maintainer is lobbying to change the way the Python programming language numbers its releases.
Hugo van Kemenade, who will be the release manager for the upcoming Python 3.14 and 3.15 releases, has authored the proposal PEP 2026, “Calendar Versioning for Python,” for how all future releases be numbered.
In short, this proposal suggests that Python versions will be numbered 3.YY.micro where:
3 is the major version number – it is always 3.
YY is the minor version number – it is the short year number: {year} – 2000.
micro is the micro version number – it is incremented for each bugfix or security release.
He noted that there would never be a Python 4. “Python 3” will be the brand going forward.
Thus, Python 3.15 would actually be 3.26, with the “26” representing the year of the release (“2026”).
Python End of Life
“This aims to make the support lifecycle clear by making it easy to see when a version was first released, and easier to work out when it will reach end of life (EOL),” van Kemenade wrote. Each Python release is supported for five years.
Since 2019, major Python updates have occurred on an annual basis, as per the release schedule set by Pep 603. This numbering would better reflect the cadence, he wrote.
Many people assume Python follows the industry standard of semantic versioning. The SemVer standard dictates a version number would be in the format of MAJOR.MINOR.PATCH, where MAJOR would be a major update (that could break API backward compatibility), MINOR would be a version with no breaking changes and PATCH would just be for patches.
This assumption that Python does semantic versioning has led to some frustrations as many yearly Python 3 releases actually break backward compatibility, though users assume otherwise as all new releases are in the 3.XX tree. But major versions are incremented after the first dot, i.e. the current release is 3.12 and the next major release, later this year, will be 3.13.
Any of these versions may come with breaking changes, flaunting SemVer convention (Python actually predates the Semantic Version standard by about 15 years).
Van Kemenade wrote and presented his proposal the Pycon 2024 conference, held last month in Pittsburgh.
Instead of adopting SemVer, van Kemenade suggested Python should go with an increasingly common Calendar Versioning (CalVer), which includes some elements of the Gregorian calendar year in the numbering.
From the presentation of Hugo van Kemenade (Python Foundation)
Canonical, for instance, uses a calendar-friendly YY.0M.micro, where the year is represented by YY, the month by oM and patched releases by the micro designation. Thus the current Ubuntu version is 24.02.
Going forward, Python releases would go this way:
3.15.0 will be released in 2026 (3.26)
3.16.0 will be released in 2027 (3.27)
3.17.0 will be released in 2028 (3.28)
3.18.0 will be released in 2029 (3.29)
3.19.0 will be released in 2030 (3.30)
And so on…
Skeptical observers on Slashdot noted that this two-number approach would be problematic around the turn of the century, where a two-digit year designation would present ambiguity, making it difficult for build systems to auto-update to the latest version of the programming language, among other issues.
In the year 2100, Python v3.00 would follow Python v3.99?
“Did Y2K teach us nothing?” one reader quipped.
The post Python Mulls a Change in Version Numbering appeared first on The New Stack.
Despite popular belief, Python does not use the industry standard semantic versioning, and this has led to frustrations around backward compatibility and End-of-Life expectancies.