osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Python version numbers


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