[Python-Dev] Python version numbers

[Guido van Rossum]

I personally see no reason to change anything.

On Tue, Apr 3, 2018 at 9:36 AM, Brett Cannon <brett at python.org> wrote:

>
>
> On Tue, 3 Apr 2018 at 07:39 Paul G <paul at ganssle.io> wrote:
>
>> > 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.
>>
>
> Paul's point is that he knows e.g. code working in 3.6.0 will work when he
> upgrades to 3.6.5, and if his code is warning-free  and works with all
> __future__ statements in 3.6 that it will work fine in 3.7. With CalVer you
> could make a similar promise if you keep the major version the year of
> release and then keep our feature/bugfix number promise like we already
> have, but at that point who cares about the year?
>
>
>>
>> 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.
>>
>
> While we have an 18 month schedule for releases, we also can't guarantee
> we will hit our release window in a specific year, e.g. 3.6 was first
> released in December but we could have slipped into January. That makes
> promises for a specific version tied to a year number problematic.
>
>
>>
>> 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.
>>
>
> We already have this with __future__ statements. The transition from 2 to
> 3 was such a big deal because we changed so much without using __future__
> statements. We've already said that going forward we are not skipping that
> step for any other releases.
>
> If we chose to switch to semantic versioning, we would probably make it so
> that any version that makes a __future__ statement the new default is a
> major version bump. But then the issue becomes the stdlib. Do we drop
> everything that was previously deprecated in the stdlib for every major
> version bump? That might be a bit drastic when e.g. all you did was make
> old code that used `await` as a variable name raise a SyntaxError. And
> saying "deprecated for two versions" then becomes messy because you have no
> idea what that second version will be. And what if you **really** want to
> get rid of something in the next release? Can a single module dropping a
> function force a version bump for Python itself?
>
> I have not read the other thread, but knowing it's from Lukasz makes me
> guess he wants to move up the minor number to become the major one in terms
> of our current semantics so we have a rolling window of support. That would
> mean that as long as you are warnings-free and run fine with all __future__
> statements turned on for version N then N+1 should work for you without
> modification (sans relying on buggy semantics). That approach would deal
> with the above issues cleanly while dropping what our current major number
> semantics which some people view as a fallacy and are getting upset over
> (I'm personally +0 on this last idea as it's easy to explain to folks and I
> have been doing Python version explanations a lot over the last several
> months).
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180403/73d0e2c5/attachment.html>