Current scheme

From the General Python FAQ: How does the Python version numbering scheme work?

Python versions are numbered “A.B.C” or “A.B”:

• A is the major version number – it is only incremented for really major changes in the language.
• B is the minor version number – it is incremented for less earth-shattering changes.
• C is the micro version number – it is incremented for each bugfix release.

Python predates SemVer

Semantic Versioning (SemVer) is a popular scheme which aims to communicate the intent of a release (though it doesn’t always succeed).

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes
2. MINOR version when you add functionality in a backward compatible manner
3. PATCH version when you make backward compatible bug fixes

People often assume Python follows SemVer and complain about breaking changes in feature releases. But Python predates SemVer by at least 15 years: the SemVer spec was introduced in 2009 and the bespoke Python scheme was added to source control in 1994 for the 1.0 release.

If Python adopted SemVer, that would imply a new major bump every year when we remove deprecations.

Instead of SemVer, however, some projects have adopted another versioning scheme based on the calendar.

Calendar versioning

With Calendar Versioning (CalVer), you include some element of the date in the version number. For example, Ubuntu and Black use the year and month – Ubuntu 24.04 came out in April 2024; pip and PyCharm use only the year.

And here are some programming language standards, all using some form of the year:

Annual release cadence

Since 2019, we’ve made a release each year:

• 3.15.0 will be released in 2026
• 3.16.0 will be released in 2027
• 3.17.0 will be released in 2028
• 3.18.0 will be released in 2029
• 3.19.0 will be released in 2030

This is sort of calendar-based, it’s just that it’s offset by 11 years.

CalVer for Python

The simplest CalVer option would be to stick with major version 3, and encode the year in the minor version:

• 3.26.0 will be released in 2026
• 3.27.0 will be released in 2027
• 3.28.0 will be released in 2028
• 3.29.0 will be released in 2029
• 3.30.0 will be released in 2030

For example, 3.26 will be released in 2026. It makes it obvious when a release first came out.

Clarity of support lifecycle

Right now, it’s a little tricky to work out when a release is end-of-life. First you have to look up when it was initially released, then add 5 years:

“When will Python 3.11 be EOL?”

“Well, let’s see… PEP 664 is the 3.11 release schedule, it says 3.11 was released in 2022, EOL after 5 years, so 2022 + 5 = 2027.”

But if the initial release year is right there in the version, it’s much easier:

“When will Python 3.26 be EOL?”

“26 + 5 = [20]31”

Non-goals

Like the current scheme, only the micro version will be incremented for bug fix and security releases, with no change to the major and minor. For example:

No change to PEP 602 (Annual Release Cycle for Python):

• No change to the 17 months to develop a feature version: alphas, betas and release candidates.
• No change to the support duration: two years of full support and three years of security fixes.
• No change to the annual October release cadence.

Version mapping

Versions 3.15 to 3.25 inclusive will be skipped. Features, deprecations and removals planned for these will be remapped to the new version numbers.

For example, a deprecation initially planned for removal in 3.16 will instead be removed in 3.27.

YY.0

For example, Python 26.0 would be released in 2026.

There’s not much appetite for Python version 4. We don’t want to repeat 2-to-3, and 4 has a lot of expectations by now. We don’t want “earth-shattering changes”.

Perhaps Python 4 could be reserved for something big like removing the GIL (PEP 703), but the Steering Council made it clear the free-threading rollout must be gradual. Will we stick with version 3 forever?

Another option would be to put the year in the major version and jump to 26.0. This could mean we could leapfrog all that 4.0 baggage.

'this is Python {}'.format(sys.version[:5])

".%s-%s" % (get_platform(), sys.version[0:3])

if sys.version_info[1] >= 9:

if sys.version[0] == '3':

YY.MM

For example, Python 26.10 would be released in October 2026.

Building upon YY.0 versioning, we could also include the release month as the minor version, like Ubuntu and Black. This would make it clear when in the year it was released, and also when in the year it will reach end-of-life.

However, YY.MM versioning is rejected for many of the same reasons as YY.0 versioning.

3.YYYY

For example, Python 3.2026 would be released in 2026.

It’s clearer that the minor version is a year when using a four digits, and avoids confusion with Ubuntu versions which use YY.MM. However, this is rejected as changing from two to four digits would break more code than 3.YY versioning.

Editions

For example, Python 3.15 (2026 Edition) would be released in 2026.

The Rust language uses “Editions” to introduce breaking changes. Applying this to Python would require big changes to PEP 387 (Backwards Compatibility Policy) and is out of scope for this PEP.

We could apply a year label to releases, such as “Python 3.15 (2026 Edition)”, but this is rejected because we’d have to keep track of two numbers.

Adopt SemVer and skip 4

For example, Python 5.0 would be released in 2026, 6.0 in 2027, and so on.

We could skip the problematic 4.0 entirely and adopt SemVer. Because deprecations are removed in every feature release, we would get a new major bump every year.

This is rejected because we wouldn’t get the benefit of calendar versioning, and moving away from 3.x would also break code.

Change during 3.14 cycle

The Python 3.14 release must go ahead because: π.