On 4 November 2017 at 23:29, Antoine Pitrou <solip...@pitrou.net> wrote: > > Hello Wolfgang, > > On Sat, 4 Nov 2017 12:25:57 +0100 (CET) > tds...@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. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
