all fixed
On Wed, Feb 2, 2011 at 03:04, Sandro Tosi <sandro.t...@gmail.com> 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)? > >> +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/brett%40python.org > _______________________________________________ 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
