Re: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for
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:
Re: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for
On 02/02/2011 11:04, Sandro Tosi wrote: On Wed, Jan 26, 2011 at 23:20, brett.cannonpython-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
Re: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for
On Wed, 2 Feb 2011 12:04:44 +0100 Sandro Tosi sandro.t...@gmail.com wrote: +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 By the way, crashers *are* a security risk. See http://code.python.org/hg/branches/release2.6-maint/ Regards Antoine. ___ 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
Re: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for
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,
