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)? > +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 > > -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi _______________________________________________ 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