[Python-Dev] Python version numbers

[Paul G]

> When programs use calendar-based versioning, I'm left with no
> information as to whether it's breaking changes or not. In fact, it
> might as well have no version numbers whatsoever. If I care about
> backward compatibility, I just have to stick with the exact same
> unpatched version that I had before. Not a good thing for a language
> that releases periodic bugfix updates to older versions.

Well, this is not true. As a general rule, you don't know if anything *you care about* breaks at a given version change anyway, and I've seen plenty of handwringing about what should and should not be considered a breaking change. A major change is basically the "nuclear option", and everything I've seen from core developers is "there will never be another major change on the scale of 2->3". Given that from an optics perspective there's no interest in creating a Python 4 and it's been repeatedly emphasized in this thread that Python doesn't use semantic versioning, I don't see how you can really say that the version number gives you much information at all about what will and will not break.

This thread started in response to a proposal to just have a rolling backwards compatibility window (e.g. no discontinuous major version changes), which is basically ideal for calendar versioning - any time you make a backwards incompatible change, you give X notice period. You can encode X directly into the deprecation warnings (e.g. "This feature will be removed in Python >= 2025"), that way users will know on a *per feature basis* where to pin, even before specific version numbers are announced.

Presumably if major breaking changes ever *do* occur, the mechanism for upgrading Python would be either to create a new program called something else (e.g. the core Python simply *does not break backwards compat*), or a slow rollout with individual feature flags that start out defaulting on (opt in to the new behavior), eventually default to off (opt out of the new behavior), and then are removed after a very long deprecation period.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180403/96a5184f/attachment.sig>