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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com