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

Ezio Melotti ezio.melotti at gmail.com
Wed Jan 18 00:50:52 CET 2012

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).

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.

[...]

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.

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.

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 given values of X and N, is the no-bugfix-releases policy for non-LTS versions feasible?

If LTS bug fix releases and feature releases are synchronized it should be feasible.

* Restrict new syntax and similar changes (i.e. everything that was prohibited by PEP 3003) to LTS versions?

(I was reading this the other way around, maybe rephrase it to "Allow new syntax and similar changes only in LTS versions")

* What is the effect on packagers such as Linux distributions?

* How will release version numbers or other identifying and marketing material make it clear to users which versions are normal feature releases and which are LTS releases? How do we manage user expectations?

This is not an issue with the scheme I proposed.

A community poll or survey to collect opinions from the greater Python community would be valuable before making a final decision.

[...]

Best Regards, Ezio Melotti

More information about the Python-Dev mailing list