On 3 April 2018 at 23:24, Paul G <p...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
