peps/pep-0407.txt at main · python/peps

Cannot retrieve contributors at this time

178 lines (129 sloc) 5.79 KB

	PEP: 407
	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>,
	Barry Warsaw <barry@python.org>
	Status: Deferred
	Type: Process
	Content-Type: text/x-rst
	Created: 12-Jan-2012
	Post-History: 17-Jan-2012


	Abstract
	========

	Finding a release cycle for an open-source project is a delicate
	exercise in managing mutually contradicting constraints: developer
	manpower, availability of release management volunteers, 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 keep the stability that has become a Python trademark,
	while offering a more fluid release of features, by introducing the
	notion of long-term support versions.


	Scope
	=====

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

	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.

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


	Effects
	=======

	Effect on development cycle
	---------------------------

	More feature releases might mean more stress on the development and
	release management teams. This is quantitatively alleviated 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 effect on fixing bugs should be minimal with the proposed figures.
	The same number of branches would be simultaneously open for bugfix
	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
	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).

	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 more
	quickly available to normal users. Also, a smaller feature freeze
	period makes it less cumbersome to interact with contributors of
	features.


	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.

	* For given values of X and N, is the no-bugfix-releases policy for
	non-LTS versions feasible?

	* What is the policy for security fixes?

	* Restrict new syntax and similar changes (i.e. everything that was
	prohibited by :pep:`3003`) to LTS versions?

	* What is the effect on packagers such as Linux distributions?

	* 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?

	* Does the faster release cycle mean we could some day reach 3.10 and
	above? Some people expressed a tacit expectation that version numbers
	always fit in one decimal digit.

	A community poll or survey to collect opinions from the greater Python
	community would be valuable before making a final decision.


	Copyright
	=========

	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: