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

Wolfgang tds333 at mailbox.org
Sat Nov 4 11:10:32 EDT 2017


Hi Nick,

On 04.11.2017 15:48, Nick Coghlan wrote:
> On 4 November 2017 at 23:29, Antoine Pitrou <solipsis at pitrou.net> 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
> 
> PEP 413 was another competing proposal from around the same time:
> https://www.python.org/dev/peps/pep-0413/
> 
> Technically neither proposal has been formally Rejected, but they're
> also Deferred/Withdrawn because we knew that if we *had* asked for an
> explicit determination, the answer would have been "No, too high a
> cost, for not enough of a demonstrated benefit" (and that hasn't
> really changed in the past 5 years).
> 
>> 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.
> 
> It's not just redistributors that get affected - it's the
> compatibility testing matrices for community projects as well.
> 
> With our current release cycles (and excluding the 2.7 LTS release
> from consideration) we tend to have the following situation for the
> 3.x branches:
> 
> - 1 actively maintained version
> - 2 or 3 security-fix only branches
> 
> This stems from the default commitment of security fixes ending around
> 5 years after an X.Y.0 release, and releases happening 18-24 months
> apart:
> 
> * Month 0: X.Y.0 released
> * Month 18: X.(Y+1).0 released
> * Month 36: X.(Y+2).0 released
> * Month 54: X.(Y+3).0 released
> * Month 60: X.Y.Z goes end-of-life
> * Month 72: X.(Y+4).0 released
> 
> That same pattern also held for the 2.x series until the 2.7 release
> in 2010 (and it only changed then because that was the last 2.x
> feature release).
> 
> The current year or so where the number of supported branches drops
> down to only 3 means we have some scope to speed up the rate of
> feature releases a bit (i.e. a release cadence of every 15 months
> instead of every 18 still means the community compatibility testing
> matrix consistently stays around 4 versions, or 5 if you're also
> testing against the dev release), but going to 6 monthly version
> updates means folks will either keep their test matrices the same as
> they are now (increasing the odds of the standard-library-only updates
> breaking things and that not being detected for some time), or else
> feeling obliged to expand their test matrices to cover even more
> concurrently supported versions. There are potential ways around both
> of those problems, but they require making the defined support periods
> for minor releases significantly shorter, unless they're the last
> minor release before the next major release (which means that instead
> of being simpler, these kinds of arrangements tend to end up being
> *more* complicated than the "every feature release receives security
> updates for 5 years" status quo).
> 
> So rather than making fundamental changes to the way Python is
> versioned just to make standard library updates more readily available
> on older base versions of Python, we've instead gone with a more needs
> driven approach: making backport modules available for older versions
> where we find it is beneficial to do so (e.g. contextlib2, unittest2,
> importlib2).
> 
> While Python 2.7 is a major driver for that change in practice, the
> benefits apply to older 3.x releases as well:
> 
> - the updated modules are available for all Python versions and
> implementations where the packaging tools work (which is most of them)
> - users can decide on a module-by-module basis whether they want the
> baseline version or fast track updates
> - those decisions are explicitly tracked in the project's dependency
> metadata, rather than being implicit in the choice of deployment
> platform
> 
> Cheers,
> Nick.
> 

This is a valid concern. So more pressure by more releases can be a problem.
For my idea the only possibility to limit this is to have minor versions
only for the provisional parts to allow improvements and to have
the major version track the core features and the bug fixing only for 
the first major version.
Resulting in something like 4.0.0, 4.0.1 and 4.1.0 for something like a 
feature update for provisional but not supported with bug fixing and not
for compatibility testing.
This is then something like PEP-407 which is rejected.
And also makes things little more complicated.


Another possibility is to change only the versioning
to major.minor instead of major.minor.patch. Then having
a simpler versioning scheme for other Python implementations
as only benefit (and the simplification to spell compatibility).

Thus major is for the compatibility and minor counts the bug fix releases.

Thinking if a change then is needed. :-) Marketing benefits?
Don't know then.

Regards,

Wolfgang






More information about the Python-ideas mailing list