[Python-ideas] Proposal to change Python version release cycle

[Chris Angelico]

On Sat, Nov 4, 2017 at 11:00 PM, Wolfgang <tds333 at mailbox.org> wrote:
>
>
> On 04.11.2017 12:35, Chris Angelico wrote:
>>
>> On Sat, Nov 4, 2017 at 10:25 PM,  <tds333 at mailbox.org> wrote:
>>>
>>> I suggest to change this to increment the major version for every new
>>> release
>>> of the 1,5 year cycle.
>>> And allow new Python standard library backward compatible changes for
>>> every
>>> minor release cycle every 6 months.
>>
>>
>> The usual implication of a major version bump is that there is
>> significant incompatibility. That's something that should happen
>> roughly once a decade, not every couple of years. Massive -1.0 from me
>> on this.
>>
>
> Yes that implication is a possible risk. I will add it to the section
> if needed.
>
> As noted by Guido a ground breaking change as it happened from version 2 to
> 3 should never happen in Python land again and a possible version 4 will
> simply be after 3.9.
> Other languages increment their major version already faster and track
> the language standard simply with the major version.
>
> The major version should be incremented for a ground breaking change
> but an increment requires not a ground breaking change to do this.
>
> For me even adding new keywords to a language is a major change.
> (Such as async and await)
> Or changes in the C API.
> And talking about language standard version 4 is simpler than a
> more complicated scheme of major.minor.
> Also other implementations such as pypy can use this first version
> number in their name to show compatibility.
> (pypy4 compatible to Python )
>
> I think if the changes happens it will take some time for people to
> adjust but then life will be simpler. :-)
>
> Thank you for your feedback.

If I write code for Python 3.4 and try to run it on Python 3.7, there
is a small probability that it will break (eg if it tries to use
"await" as a function name - I had a program like that, and once the
new keywords were pushed through, I renamed it to "wait" to ensure
compatibility). But it's a fairly small chance, and it's usually
pretty easy to write code that's compatible with several minor
versions (by targeting the oldest and then testing on the newer ones).
With major version changes, it's much harder to be compatible with
both, and you often end up with compatibility shims (eg "try: input =
raw_input; except NameError: pass"). This applies to code, to
documentation, to answers on Stack Overflow, to blogs, and to
everything else that discusses Python in any way.

At work, we have to use certain JavaScript packages that have had, I
kid you not, more than one major version bump per year since initial
release. One time we only discovered an issue after a student
installed the latest version of something, and the setup instructions
didn't work. Oh, great, version 10 breaks things compared to version
9. I do NOT enjoy dealing with that kind of incompatibility, and
permitting it every 1.5 years is a bad thing.

And if compatibility is to be guaranteed, why bump the major version
number? That's the whole point of the three-part version.

ChrisA