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

[Nick Coghlan]

On 5 November 2017 at 01:29, Wolfgang <tds333 at mailbox.org> wrote:
> On 04.11.2017 16:01, Nick Coghlan wrote:
>> We're currently more likely to go the other direction, and stick with
>> the 3.x numbering for an extended period (potentially reaching 3.10,
>> 3.11, 3.12, etc), so that the ongoing disruption caused by the 2.x ->
>> 3.x transition has had a chance to settle down before we ask anyone to
>> start calling anything "Python 4".
>
> A good point but two digits minor version numbers have the possibility
> to break a lot code. There is a lot of stuff out where a single digit
> major version is assumed. Even the official Python build for windows
> with python27.dll, python36.dll can be problematic because the dot
> is omitted between numbers.
> Other do the same for compilation they concatenate only majorminor for a
> name.
> Then version 3.10 is the same as 31.0.
> Ok I know this will take a while.
> But for the first 2.7.10 version even there some other library code
> was broken because of such assumptions.

Aye, we're aware :)

We're not in a situation where we'll have any *good* options
available, so the question we're considering is "What do we think will
be the least bad approach?".

At our current release cadence, 3.7 will be in mid 2018, 3.8 in late
2019 or early 2020, and then 3.9 in mid 2021.

The open question will be what we call the release after that (in late
2022), with the main leading contenders being "4.0" (on the grounds
that so many changes will have accumulated since 2008's 3.0 release by
then that it makes sense to call them different major versions,
similar to the rationale the Linux kernel now uses for major version
updates), and "3.10" (on the grounds that the release won't be any
more different from 3.9 than 3.9 will be from 3.8). Other variants
(like making the major release number "40" or "2022", and using the
minor version field for some new purpose other than indicating
compatibility breaks in the compiler AST, interpreter opcode format,
code caching tags, and C ABI), tend to introduce the same pragmatic
questions that will already need to be considered in choosing between
the 3.10 and 4.0 alternatives.

It's not just the version numbering aesthetics that need to be
considered either - in addition to the point you raise around how the
Python version gets embedded in file path names (such that the 3-digit
form is technically ambiguous without a separator, and may break
parsers that are expecting exactly two digits), there are other
backwards compatibility concerns around how folks do version
compatibility checks based on sys.version and sys.version_info. Python
and CPython will be more than 3 decades old by 2022, and an ecosystem
can build up a *lot* of implicit assumptions regarding how a
platform's versioning scheme works in that kind of time frame :)

Personally, I doubt we'll make a firm decision on how we're going to
handle this until some time after 2.7 goes EOL in 2020, as by then
we'll necessarily have a better idea of how the various Linux distros
(including the LTS commercial ones) ended up handling the Python 2 ->
Python 3 switch, and the fact that the next release at that point will
be 3.9 making it eminently clear that we've run out of time to
continue postponing the question. We'll hopefully also have more
experience with folks relying on the stable runtime ABI, and hence
whether or not it might be beneficial to define new "py4" and "abi4"
compatibility tags for the binary wheel distribution format.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia