Commits

Georg Brandl committed 9eb7fb8

Some edits, and mainly XXXs.

  • Participants
  • Parent commits d967ebf

Comments (0)

Files changed (1)

 PEP: XXX
-Title: New release cycle
+Title: New release cycle and introducing long-term support versions
 Version: $Revision$
 Last-Modified: $Date$
 Author: Antoine Pitrou <solipsis@pitrou.net>, Georg Brandl <georg@python.org>
 Abstract
 ========
 
-Finding a release cycle is a delicate exercise in managing mutually
-contradicting constraints: developer manpower, release management volunteership,
-ease of maintenance for users and third-party packagers, quick availability
-of new features (and behavioural changes), availability of bug fixes without
-pulling in new features or behavioural changes.
+Finding a release cycle for an open-source project is a delicate
+exercise in managing mutually contradicting constraints: developer
+manpower, release management volunteership, ease of maintenance for
+users and third-party packagers, quick availability of new features
+(and behavioural changes), availability of bug fixes without pulling
+in new features or behavioural changes.
 
-The current release cycle errs on the conservative side.  It is adequate
-for people who value stability over reactivity.  This PEP is an attempt to
-bridge the gap better.
+The current release cycle errs on the conservative side.  It is
+adequate for people who value stability over reactivity.  This PEP is
+an attempt to keep the stability that has become a Python trademark,
+while offering more XXX, by introducing the notion of long-term
+support versions.
+
+.. XXX I was unsuccessfully searching for words there
 
 
 Scope
 =====
 
-This PEP doesn't try to change the maintenance or release scheme for the
-2.7 branch.  Only 3.x versions are considered.
+This PEP doesn't try to change the maintenance period or release
+scheme for the 2.7 branch.  Only 3.x versions are considered.
 
 
 Proposal
 ========
 
-Under the proposed scheme, there would be two kind of feature versions
-(sometimes dubbed "minor versions", for example 3.2 or 3.3): normal feature
-versions and long-term support (LTS) versions.
+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.
+Normal feature versions would get either zero or at most one bugfix
+release; the latter only if needed to fix critical issues.
 
-LTS versions would get regular bugfix releases until the next LTS version
-is out.  Then they would go into security fixes mode, up to a termination
-date at the security release manager's discretion.
+.. XXX I think we have to discuss this: it depends on the chosen cycle
+   duration (I'd rather have X = 8 and N = 3, and for that it makes
+   sense to have bugfix releases IMO.)
+
+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 security release manager's discretion.
+
+.. XXX we also have to discuss that: it makes LTS no different from
+   current feature releases
 
 Periodicity
 -----------
 
-A new feature version would be released every X months.  We temptatively
-propose X = 6 months.
+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 temptatively
+LTS versions would be one out of N feature versions.  We tentatively
 propose N = 4.
 
-With these figures, a new LTS version would be out every 24 months, and
-remain supported until the next LTS version 24 months later.  This is mildly
-similar to today's 18 months bugfix cycle for every feature version.
+With these figures, a new LTS version would be out every 24 months,
+and remain supported until the next LTS version 24 months later.  This
+is mildly similar to today's 18 months bugfix cycle for every feature
+version.
 
 Pre-release versions
 --------------------
 
-More frequent feature releases imply a lesser number of disruptive changes
-per release.  Therefore, the number of pre-release builds (alphas and betas)
-can be brought down considerably.  A single alpha build and a single beta
-build would probably be enough.  The number of release candidates depends,
-as usual, on the number of necessary fixes before final release.
+More frequent feature releases imply a smaller number of disruptive
+changes per release.  Therefore, the number of pre-release builds
+(alphas and betas) can be brought down considerably.  Two alpha builds
+and a single beta build would probably be enough in the regular case.
+The number of release candidates depends, as usual, on the number of
+last-minute fixes before final release.
+
+.. XXX I put in "two alphas"; IMO one alpha is not enough given our
+   tendency to shove in things during the alpha period -- also, Nick's
+   comments about early alphas apply
+
+
+Effects
+=======
 
 Effect on development cycle
 ---------------------------
 
-More feature releases might mean more stress on the development and release
-management team.  This is quantatively alleviated, though, by the lesser
-number of pre-release versions; and qualitatively by the lesser amount of
-disruptive changes (meaning less potential for breakage).  The shorter
-feature freeze period (after the first beta build until the final release)
-is easier to accept.  The rush for adding features just before feature
-freeze should also be much smaller.
+More feature releases might mean more stress on the development and
+release management teams.  This is quantatively alleviated, though, by
+the smaller number of pre-release versions; and qualitatively by the
+lesser amount of disruptive changes (meaning less potential for
+breakage).  The shorter feature freeze period (after the first beta
+build until the final release) is easier to accept.  The rush for
+adding features just before feature freeze should also be much
+smaller.
 
 Effect on bugfix cycle
 ----------------------
 The same number of branches would be simultaneously open for regular
 maintenance (two until 2.x is terminated, then one).
 
+.. XXX that is true in your original proposal, but see above
+
 Effect on workflow
 ------------------
 
 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``.
+commit bug fixes to the current LTS branch (for example ``3.3``) and
+then merge them into ``default``.
 
-If some critical fixes are needed to a non-LTS version, they can be committed
-first to the current LTS branch (e.g. ``3.3``) and then merged to the
-non-LTS branch (e.g. ``3.5``).  Or the necessary changeset(s) can be
-grafted manually, at the release manager's discretion.
+If some critical fixes are needed to a non-LTS version, they can be
+committed first to the current LTS branch (e.g. ``3.3``) and then
+merged to the non-LTS branch (e.g. ``3.5``).
+
+.. XXX no they can't, since that will merge all other fixes too.
+
+Or the necessary changeset(s) can be grafted manually, at the release
+manager's discretion.
 
 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).
+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).
 
-People who value reactivity and access to new features (without taking the
-risk to install alpha versions or Mercurial snapshots) would get much more
-value from the new release cycle than currently.
+People who value reactivity and access to new features (without taking
+the risk to install alpha versions or Mercurial snapshots) would get
+much more value from the new release cycle than currently.
 
-People who want to contribute new features or improvements would be more
-motivated to do so, knowing that their contributions will be quickly
-available to normal users.  Also, a smaller feature freeze period makes
-it less cumbersome to interact with contributors of features.
+People who want to contribute new features or improvements would be
+more motivated to do so, knowing that their contributions will be more
+quickly available to normal users.  Also, a smaller feature freeze
+period makes it less cumbersome to interact with contributors of
+features.
+
+
+.. XXX section "effect on distributions" is missing; but probably that
+   can come with the python-dev discussion where the responsibles for
+   the different distros can weigh in
+
 
 Discussion
-----------
+==========
 
-We could set up a community poll or survey before making a final decision.
+A community poll or survey to collect opinions from the greater Python
+community would be valuable before making a final decision.
 
 
 Copyright