[Python-checkins] devguide: Update the devguide to reflect workflow changes as a result of

[ned.deily]

http://hg.python.org/devguide/rev/e125591a5f12
changeset:   615:e125591a5f12
user:        Ned Deily <nad at acm.org>
date:        Sat Mar 30 12:11:37 2013 -0700
summary:
  Update the devguide to reflect workflow changes as a result of
the 3.2 branch changing to security-fix-only mode.

files:
  committing.rst |  21 ++++++++-------------
  devcycle.rst   |  17 +++++++++--------
  faq.rst        |  14 +++++++-------
  3 files changed, 24 insertions(+), 28 deletions(-)


diff --git a/committing.rst b/committing.rst
--- a/committing.rst
+++ b/committing.rst
@@ -320,15 +320,10 @@
    $ hg import --no-c http://bugs.python.org/url/to/the/patch.diff
    $ # review, run tests, run `make patchcheck`
    $ hg ci -m '#12345: fix some issue.'
-   $ # switch to 3.2 and port the changeset using `hg graft`
-   $ cd ../3.2
+   $ # switch to 3.3 and port the changeset using `hg graft`
+   $ cd ../3.3
    $ hg up
    $ hg graft 2.7
-   $ # switch to 3.3, merge, and commit
-   $ cd ../3.3
-   $ hg up
-   $ hg merge 3.2
-   $ hg ci -m '#12345: merge with 3.2.'
    $ # switch to 3.x, merge, commit, and push everything
    $ cd ../3.x
    $ hg up
@@ -404,13 +399,13 @@
 Porting changesets between the two major Python versions (2.x and 3.x)
 ----------------------------------------------------------------------
 
-Assume you just committed something on ``2.7``, and want to port it to ``3.2``.
+Assume you just committed something on ``2.7``, and want to port it to ``3.3``.
 You can use ``hg graft`` as follow::
 
-   cd ../3.2
+   cd ../3.3
    hg graft 2.7
 
-This will port the latest changeset committed in the 2.7 clone to the 3.2 clone.
+This will port the latest changeset committed in the 2.7 clone to the 3.3 clone.
 ``hg graft`` always commits automatically, except in case of conflicts, when
 you have to resolve them and run ``hg graft --continue`` afterwards.
 Instead of the branch name you can also specify a changeset id, and you can
@@ -418,15 +413,15 @@
 
 On older version of Mercurial where ``hg graft`` is not available, you can use::
 
-    cd ../3.2
+    cd ../3.3
     hg export 2.7 | hg import -
 
 The result will be the same, but in case of conflict this will create ``.rej``
 files rather than using Mercurial merge capabilities.
 
-A third option is to apply manually the patch on ``3.2``.  This is convenient
+A third option is to apply manually the patch on ``3.3``.  This is convenient
 when there are too many differences with ``2.7`` or when there is already a
-specific patch for ``3.2``.
+specific patch for ``3.3``.
 
 .. warning::
     Never use ``hg merge`` to port changes between 2.x and 3.x (or vice versa).
diff --git a/devcycle.rst b/devcycle.rst
--- a/devcycle.rst
+++ b/devcycle.rst
@@ -31,12 +31,12 @@
 ''''''''
 
 There is a branch for each *feature version*, whether released or not (e.g.
-2.7, 3.2, 3.3).  Development is handled separately for Python 2 and Python 3:
+2.7, 3.3).  Development is handled separately for Python 2 and Python 3:
 no merging happens between 2.x and 3.x branches.
 
 In each of the 2.x and 3.x realms, the branch for a feature version is always a
-descendant of the previous feature version: for example, the ``3.2`` branch is a
-descendant of the ``3.1`` branch.
+descendant of the previous feature version: for example, the ``3.3`` branch is a
+descendant of the ``3.2`` branch.
 
 Therefore, each change should be made **first** in the oldest branch to which it
 applies and forward-ported as appropriate: if a bug must be fixed in both Python
@@ -77,10 +77,12 @@
 discussed first.
 
 Sometime after a new maintenance branch is created (after a new *minor version*
-is released), the old maintenance branch on that major version (e.g. 3.2.x
-after 3.3 gets released) will go into :ref:`security mode <secbranch>`,
+is released), the old maintenance branch on that major version will go into
+:ref:`security mode <secbranch>`,
 usually after one last maintenance release at the discretion of the
-release manager.
+release manager.  For example, the 3.2 maintenance branch was put into
+:ref:`security mode <secbranch>` after the 3.2.4 final maintenance release
+following the release of 3.3.0.
 
 .. _secbranch:
 
@@ -107,8 +109,7 @@
 - the ``default`` branch holds the future 3.4 version and descends from ``3.3``
 - the ``3.3`` branch holds bug fixes for future 3.3.x maintenance releases
   and descends from ``3.2``
-- the ``3.2`` branch holds bug fixes for an upcoming final 3.2.4 maintenance
-  release and then for future 3.2.x security releases
+- the ``3.2`` branch holds security fixes for future 3.2.x security releases
 - the ``3.1`` branch holds security fixes for future 3.1.x security releases
 - the ``2.7`` branch holds bug fixes for future 2.7.x maintenance releases and
   descends from ``2.6``
diff --git a/faq.rst b/faq.rst
--- a/faq.rst
+++ b/faq.rst
@@ -174,7 +174,7 @@
     git clone git://github.com/akheron/cpython
 
 The mirror's master branch tracks the main repository's default branch,
-while the maintenance branch names (``2.7``, ``3.2``, etc) are mapped
+while the maintenance branch names (``2.7``, ``3.3``, etc) are mapped
 directly.
 
 .. _git mirror: http://github.com/akheron/cpython
@@ -796,14 +796,14 @@
 How do I make a null merge?
 '''''''''''''''''''''''''''
 
-If you committed something (e.g. on 3.2) that shouldn't be ported on newer
-branches (e.g. on 3.3), you have to do a *null merge*::
+If you committed something (e.g. on 3.3) that shouldn't be ported on newer
+branches (e.g. on default), you have to do a *null merge*::
 
-   cd 3.3
-   hg merge 3.2
-   hg revert -ar 3.3
+   cd 3.x
+   hg merge 3.3
+   hg revert -ar default
    hg resolve -am  # needed only if the merge created conflicts
-   hg ci -m '#12345: null merge with 3.2.'
+   hg ci -m '#12345: null merge with 3.3.'
 
 Before committing, ``hg status`` should list all the merged files as ``M``,
 but ``hg diff`` should produce no output.  This will record the merge without

-- 
Repository URL: http://hg.python.org/devguide