+Title: New release cycle
+Author: Antoine Pitrou <email@example.com>
+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
+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
+LTS versions would be one out of N feature versions. We temptatively
+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.
+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.
+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).
+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.
+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.
+ sentence-end-double-space: t