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

[Wolfgang]

Hi Nick,

On 04.11.2017 16:01, Nick Coghlan wrote:
> On 5 November 2017 at 00:40, Wolfgang <tds333 at mailbox.org> wrote:
>>
>>
>> On 04.11.2017 14:29, Antoine Pitrou wrote:
>>>
>>>
>>> Hello Wolfgang,
>>>
>>> On Sat, 4 Nov 2017 12:25:57 +0100 (CET)
>>> tds333 at mailbox.org wrote:
>>>>
>>>> Hello,
>>>>
>>>> one of my long standing ideas to improve Python is to adjust the
>>>> release cycle and version number handling. In short, to simplify it.
>>>
>>>
>>> There has been ample discussion in the past about changing our release
>>> cycle one way or another. In short, the meta-problem is there are many
>>> contradicting interests which would each favour a different solution to
>>> the problem.  See for example this PEP (ultimately rejected):
>>> https://www.python.org/dev/peps/pep-0407/
>>>
>>> and the discussion that ensued:
>>>
>>> https://mail.python.org/pipermail/python-dev/2012-January/thread.html#115591
>>>
>>> I haven't read your proposal in detail, but I suspect that it may be
>>> vulnerable to some of the same objections.  The big objection being
>>> that a significant part of our ecosystem (that is, to put it roughly,
>>> the more corporate-minded segment, though I believe it is a
>>> simplification and may include other segments, such as Debian stable
>>> users and maintainers) doesn't want to deal more frequent feature
>>> releases.
>>
>>
>> I read this PEP and some of the discussion.
>>
>> The difference to my idea is not to propose a LTS version and feature
>> preview releases.
>>
>> The simplest form of my change is to switch from today major.minor to simply
>> major for the feature release cycle.
> 
> 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.

> While the problems Linux distros are facing with whether "python"
> should refer to "python2" or "python3" are at least arguably
> self-inflicted (especially for those that already dealt with the
> Python 1.5.2 -> Python 2.0 migration back in the early 2000s), nobody
> is really looking forward to having to figure out how to adjust to a
> potential future Python 4.0 that invalidates all the current "python3"
> based naming schemes that have been introduced to work around the fact
> that Python 3.x needed to be parallel installable with Python 2.x
> without breaking any existing Python 2.x applications. We're not even
> sure yet when we're going to update PEP 394 to say that we think it's
> reasonable for distros to start using "python" to mean "python3" (see
> https://www.python.org/dev/peps/pep-0394/ and
> https://github.com/python/redistributor-guide/issues/1 for more
> discussion on the latter point).

I know on some build computers I have the same problem.
But solved it for my scripts by using the major number as compatibility 
specifier and it works fine for me.
Also knowing it is not upward compatible.

The whole problem can only be solved by something used for Windows
where the Python launcher deals with this. A Python launcher (py) for
Linux can solve this there. Allowing also distributions to configure a
fall back.

For example the user specified python3 but I know it will be compatible 
with python4 so the launcher can do something like
python3 is not found then I use python4 if available.

ex.:

#!/usr/bin/env py -3

And handle it as configurable version hint. Or even allowing alternative 
implementation like pypy if compatible.

Regards,

Wolfgang