[Python-Dev] PEP 407: New release cycle and introducing long-term support versions (original) (raw)

Georg Brandl g.brandl at gmx.net
Wed Jan 18 09:00:55 CET 2012

Am 18.01.2012 00:50, schrieb Ezio Melotti:

Hi,

On 17/01/2012 22.34, Antoine Pitrou wrote: [...]

Proposal ======== Under the proposed scheme, there would be two kinds of feature versions (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 bugfix release; the latter only if needed to fix critical issues. Security fix handling for these branches needs to be decided. If non-LTS releases won't get bug fixes, a bug that is fixed in 3.3.x might not be fixed in 3.4, unless the bug fixes releases are synchronized with the new feature releases (see below).

That's already the case today. 3.2.5 might be released before 3.3.1 and therefore include bugfixes that 3.3.0 doesn't. True, there will be a 3.3.1 afterwards that does include it, but in the new case, there will be a new feature release instead.

LTS versions would get regular bugfix releases until the next LTS version is out. They then would go into security fixes mode, up to a termination date at the release manager's discretion.

Periodicity ----------- A new feature version would be released every X months. We tentatively propose X = 6 months. LTS versions would be one out of N feature versions. We tentatively propose N = 4. If LTS bug fixes releases and feature releases are synchronized, we will have something like: 3.3 3.3.1 / 3.4 3.3.2 / 3.5 3.3.3 / 3.6 3.7 3.7.1 / 3.8 ... so every new feature release will have all the bug fixes of the current LTS release, plus new features. With this scheme we will soon run out of 1-digit numbers though. Currently we already have a 3.x release every ~18 months, so if we keep doing that (just every 24 months instead of 18) and introduce the feature releases in between under a different versioning scheme, we might avoid the problem. This means: 3.1 ... 18 months, N bug fix releases... 3.2 ... 18 months, N bug fix releases ... 3.3 LTS ... 24 months, 3 bug fix releases, 3 feature releases ... 3.4 LTS ... 24 months, 3 bug fix releases, 3 feature releases ... 3.5 LTS In this way we solve the numbering problem and keep a familiar scheme (all the 3.x will be LTS and will be released as the same pace as before, no need to mark some 3.x as LTS). OTOH this will make the feature releases less "noticeable" and people might just ignore them and stick with the LTS releases. Also we would need to define a versioning convention for the feature releases.

Let's see how Guido feels about 3.10 first.

[...]

Effect on bugfix cycle ---------------------- The effect on fixing bugs should be minimal with the proposed figures. The same number of branches would be simultaneously open for regular maintenance (two until 2.x is terminated, then one). Wouldn't it still be two? Bug fixes will go to the last LTS and on default, features only on default.

"Maintenance" excludes the feature development branch here. Will clarify.

Effect on workflow ------------------

The workflow for new features would be the same: developers would only commit them on the default branch. The workflow for bug fixes would be slightly updated: developers would commit bug fixes to the current LTS branch (for example 3.3) and then merge them into default. So here the difference is that instead of committing on the previous release (what currently is 3.2), we commit it to the previous LTS release, ignoring the ones between that and default.

Yes.

If some critical fixes are needed to a non-LTS version, they can be grafted from the current LTS branch to the non-LTS branch, just like fixes are ported from 3.x to 2.7 today.

Effect on the community ----------------------- People who value stability can just synchronize on the LTS releases which, with the proposed figures, would give a similar support cycle (both in duration and in stability). That's why I proposed to keep the same versioning scheme for these releases, and have a different numbering for the feature releases. [...] Discussion ========== These are open issues that should be worked out during discussion: * Decide on X (months between feature releases) and N (feature releases per LTS release) as defined above. This doesn't necessarily have to be fixed, especially if we don't change the versioning scheme (so we don't need to know that we have a LTS release every N releases).

For these relatively short times (X = 6 months), I feel it is important to fix the time spans to have predictability for our developers.

Georg

More information about the Python-Dev mailing list