http://hg.python.org/devguide/rev/e125591a5f12 changeset: 615:e125591a5f12 user: Ned Deily <nad@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