Finding a release cycle for an open-source project is a delicateexercise in managing mutually contradicting constraints: developermanpower, availability of release management volunteers, ease ofmaintenance for users and third-party packagers, quick availability ofnew features (and behavioural changes), availability of bug fixeswithout pulling in new features or behavioural changes.
The current release cycle errs on the conservative side. It isadequate for people who value stability over reactivity. This PEP isan attempt to keep the stability that has become a Python trademark,while offering a more fluid release of features, by introducing thenotion of long-term support versions.
This PEP doesn’t try to change the maintenance period or releasescheme for the 2.7 branch. Only 3.x versions are considered.
Under the proposed scheme, there would be two kinds of featureversions (sometimes dubbed “minor versions”, for example 3.2 or 3.3):normal feature versions and long-term support (LTS) versions.
Normal feature versions would get either zero or at most one bugfixrelease; the latter only if needed to fix critical issues. Securityfix handling for these branches needs to be decided.
LTS versions would get regular bugfix releases until the next LTSversion is out. They then would go into security fixes mode, up to atermination date at the release manager’s discretion.
A new feature version would be released every X months. Wetentatively propose X = 6 months.
LTS versions would be one out of N feature versions. We tentativelypropose N = 4.
With these figures, a new LTS version would be out every 24 months,and remain supported until the next LTS version 24 months later. Thisis mildly similar to today’s 18 months bugfix cycle for every featureversion.
More frequent feature releases imply a smaller number of disruptivechanges per release. Therefore, the number of pre-release builds(alphas and betas) can be brought down considerably. Two alpha buildsand a single beta build would probably be enough in the regular case.The number of release candidates depends, as usual, on the number oflast-minute fixes before final release.
More feature releases might mean more stress on the development andrelease management teams. This is quantitatively alleviated by thesmaller number of pre-release versions; and qualitatively by thelesser amount of disruptive changes (meaning less potential forbreakage). The shorter feature freeze period (after the first betabuild until the final release) is easier to accept. The rush foradding features just before feature freeze should also be muchsmaller.
The effect on fixing bugs should be minimal with the proposed figures.The same number of branches would be simultaneously open for bugfixmaintenance (two until 2.x is terminated, then one).
The workflow for new features would be the same: developers would onlycommit them on thedefault branch.
The workflow for bug fixes would be slightly updated: developers wouldcommit bug fixes to the current LTS branch (for example3.3) andthen merge them intodefault.
If some critical fixes are needed to a non-LTS version, they can begrafted from the current LTS branch to the non-LTS branch, just likefixes are ported from 3.x to 2.7 today.
People who value stability can just synchronize on the LTS releaseswhich, with the proposed figures, would give a similar support cycle(both in duration and in stability).
People who value reactivity and access to new features (without takingthe risk to install alpha versions or Mercurial snapshots) would getmuch more value from the new release cycle than currently.
People who want to contribute new features or improvements would bemore motivated to do so, knowing that their contributions will be morequickly available to normal users. Also, a smaller feature freezeperiod makes it less cumbersome to interact with contributors offeatures.
These are open issues that should be worked out during discussion:
A community poll or survey to collect opinions from the greater Pythoncommunity would be valuable before making a final decision.
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-0407.rst
Last modified:2025-02-01 08:59:27 GMT