On 02/02/2011 11:04, Sandro Tosi wrote:
On Wed, Jan 26, 2011 at 23:20, brett.cannon<python-check...@python.org> wrote:
+The in-development branch is where new functionality and semantic changes
new functionalities (dunno if it's plural in english or not)?
It's an odd one. Functionality can be implicitly plural (include several
individual features that comprise new functionality) but can also be
pluralised; several functionalities where each new functionality
comprises plural features. I would say that Brett's wording reads
correctly here.
Michael
+occur. Currently this branch is known as the "py3k" branch. The next minor
+release of Python will come from this branch (major releases are once a decade
+and so have no specific rules on how they are started). All changes land in
this
+branch and then trickle down to other branches.
+
+Once a Final_ release is made from the in-development branch, a branch is made
+to represent the minor version of Python and it goes into maintenance mode.
+Typically a minor version of Python is under development for about 18 months.
+
+
+Maintenance
+-----------
+The branch currently being maintained for bug fixes.
+
+The branch under maintenance is the last minor version of Python to be released
+as Final_. This means that the latest release of Python was 3.1.2, then the
if the latest release ?
+branch representing Python 3.1 is in maintenance mode.
+
+The only changes allowed to occur in a maintenance branch without debate are
bug
+fixes.
+Semantic changes **must** be carefully considered as code out in the world will
+have already been developed that will rely on the released semantics. Changes
+related to semantics should be discussed on python-dev before being made.
+
+A branch stays in maintenance mode as long as a new minor release has not been
+made. For example, this means that Python 2.6 stayed in maintenance mode until
+Python 2.7.0 was released, at which point 2.7 went into maintenance mode and
+2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18
+month schedule, a branch stays in mainteance mode for the same amount of time.
s/mainteance/maintenance/
+
+A micro release of a maintenance branch is made about every six months.
+Typically when a new minor release is made one more release of the new-old
+version of Python is made.
+
+
+Security
+--------
+A branch less than five years old but no longer in maintenance mode.
+
+The only changes made to a branch that is being maintained for security
+purposes are somewhat obviously those related to security, e.g., privilege
+escalation. Crashers and other behaviorial issues are **not** considered a
s/Crashers/Crashes/
s/behaviorial/behavioral/
+security risk and thus not backported to a branch being maintained for
+security. Any releases made for a branch under security maintenance is
s/releases/release/ ?
s/for/from/
+source-only and done only when actual security patches have been applied to the
+branch.
+
+
+Stages
+''''''
+
+Based on what stage the in-development version of Python is in, the
+responsibilities of a core developer change in regards to commits to the VCS.
+
+
+Pre-alpha
+---------
+This is the stage a branch is in from the last final release until the first
+alpha (a1). There are no special restrictions placed on commits beyond those
+imposed by the type of branch being worked on (e.g., in-development vs.
+maintenance).
+
+
+Alpha
+-----
+Alphas typically serve as a reminder to core developers that they need to start
+getting in changes that change semantics or add something to Python as such
+things should not be added during a Beta_. Otherwise no new restrictions are in
+place while in alpha.
+
+
+Beta
+----
+A branch in beta means that no new additions to Python are accepted. Bugfixes
+and the like are still fine. Being in beta can be viewed much like being in RC_
+but without the extra overhead of needing commit reviews.
+
+
+.. _RC:
+
+Release Candidate (RC)
+----------------------
+A branch preparing for an RC release can only have bugfixes applied that have
+been reviewed by other core developers. That reviewer should make a post to the
+issue related to the change and be mentioned in the commit message.
+
+You **cannot** skip the peer review during an RC, no matter how small! Even if
+it is a simple copy-and-paste change, **everything** requires peer review from
+a core developer.
+
+
+Final
+-----
+When a final release is being cut, only the release manager (RM) can make
+changes to the branch.
diff --git a/index.rst b/index.rst
--- a/index.rst
+++ b/index.rst
@@ -20,6 +20,7 @@
coredev
developers
committing
+ devcycle
stdlibchanges
langchanges
@@ -64,6 +65,7 @@
* :ref:`coredev`
* :ref:`developers`
* :ref:`committing`
+ * :ref:`devcycle`
Proposing changes to Python itself
--
Repository URL: http://hg.python.org/devguide
_______________________________________________
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
_______________________________________________
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
