1. python_mirrors
  2. sandbox/relpep


Antoine Pitrou  committed 3cf747a

Initial commit

  • Participants
  • Branches default

Comments (0)

Files changed (1)

File pep-REL.txt

View file
  • Ignore whitespace
+Title: New release cycle
+Version: $Revision$
+Last-Modified: $Date$
+Author: Antoine Pitrou <solipsis@pitrou.net>
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 2012-01-12
+Resolution: TBD
+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.
+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.
+This PEP doesn't try to change the maintenance or release scheme for the
+2.7 branch.  Only 3.x versions are considered.
+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.
+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.
+A new feature version would be released every X months.  We temptatively
+propose X = 6 months.
+LTS versions would be one out of N feature versions.  We temptatively
+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.
+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.
+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.
+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).
+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``.
+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.
+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 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.
+We could set up a community poll or survey before making a final decision.
+This document has been placed in the public domain.
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   coding: utf-8
+   End: