[Python-Dev] Python version numbers (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Tue Apr 3 10:10:38 EDT 2018

On 3 April 2018 at 23:24, Paul G <paul at ganssle.io> wrote:

That documentation seems like a "layman's explanation" of how semantic versioning works. I suspect anyone familiar with semantic versioning will read that and think, "Ah, yes, this is a semantic versioning scheme."

Anyone that reads the porting section in one of our What's New documents will quickly learn that we don't use semantic versioning - we use rolling deprecation windows, and have done so for decades :)

Regardless of the semantics (har har) of whether Python "follows strict semantic versioning", a change to the versioning scheme (CalVer should be backwards compatible with SemVer, mind you, since (21, 0, 0) > (3, 8, 0)) should make it absolutely clear that Python is not following SemVer.

Counter-intuitively, I think the fact of pinning the major version number to 3 is a worse signal of "we're not going to break everything" than switching to CalVer could. By switching to CalVer, you are removing the ability to signal a discontinuous major breaking change just by the version number. It is very much a "burn your boats so you can't retreat" philosophy to versioning.

The reason for sticking with 3.x for a while is because of the corner *nix systems have gotten stuck into regarding the "python" symlink, and the fact it currently still points to "python2" (if it exists at all). Once we've updated PEP 394 to recommend pointing it at Python 3 (which is currently looking like it might happen around the 3.8 or 3.9 time frame), then we can start talking about instead pointing it at python 4.x, and making "python3" just be a confusingly named symlink to python4.x.

That consideration applies regardless of whether the version change following the last 3.x release is a simple major version increment to python 4.x or to something CalVer based like python 22.x

Of course, if we want to reserve the ability to have sudden and major breaking changes, then yes, sticking with the current semi-SemVer system is fine, but I suspect that the fact that minor releases can break backwards compatibility will be confusing and annoying for most people (not me, because I know about it and I test against nightly), and as long as there's a "3" in the "major" slot, people will speculate about the possibility of a "4".

Indeed, but the details of Python's version numbering scheme have a lot of backwards compatibility implications, as even we haven't always been diligent about including separators between the segments of the version number in various use cases (e.g. wheel compatibility tags allow the use of underscores for disambiguation, but I'd bet at least some code doesn't currently handle that correctly). That means going to a scheme like "22.x" would risk emitting version number that sort lexically lower than "27" in some contexts.

Since it's a "not to be resolved until after 3.9" problem regardless, we have time to consider how we want to handle it :)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list