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