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

Wolfgang tds333 at mailbox.org
Sat Nov 4 10:40:09 EDT 2017



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.
Additional minor feature releases for the standard library can also be 
optional or limited to provisional parts of the standard library.
In all cases they should be backward compatible.
But have the option to change the Python parts faster than the core.

My idea came up because I have seen the need to improve the standard 
library in a faster pace than the core language. And to show this also
in the version number.
Hopefully ending the if it is included into the Python standard library 
it will be dead.

Resulting in more releases but for the core with the same release cycle
as of now. The amount of minor releases is not high it will be kept
lower as it is now.

Another point is to show by a higher major version number how mature 
Python is. (marketing) ;-)

For Linux distributions there is still the option to include a
specific Python Version with a feature set and recommend it.
If someone wants to be conservative it is save to rely on features
only for the first major version. This will be the same as of now
for major.minor.


Regards,

Wolfgang


More information about the Python-ideas mailing list