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

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

> 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?

* What is the effect on PyPy/Jython/IronPython?  Can they just skip the 
feature releases and focus on the LTS ones?

> * 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