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

[MRAB]

On 2017-11-05 03:07, Nick Coghlan wrote:
> 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.
> 
If there are 2 digits, it's major + minor.
We could decide that if there are 3 digits, it's major + double-digit 
minor (e.g. "310" is "3.10"), and we could switch to major.minor when we 
get to Python 4.0 (or Python 10?).