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

[Georg Brandl]

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