# HG changeset patch # Parent 08f963e19a3ee735fd74218f3e59deed0c40c99f diff --git a/committing.rst b/committing.rst --- a/committing.rst +++ b/committing.rst @@ -263,7 +263,7 @@ If the patch is a bugfix and it does not break backwards-compatibility *at all*, then it should be applied to the oldest branch applicable and forward-ported until it reaches the in-development branch -of Python (for example, first in ``3.1``, then in ``3.2`` and finally in +of Python (for example, first in ``3.2``, then in ``3.3`` and finally in ``default``). A forward-port instead of a back-port is preferred as it allows the :abbr:`DAG (directed acyclic graph)` used by hg to work with the movement of the patch through the codebase instead of against it. @@ -286,32 +286,32 @@ Porting Within a Major Version '''''''''''''''''''''''''''''' -Assume that Python 3.3 is the current in-development version of Python and that -you have a patch that should also be applied to Python 3.2. To properly port +Assume that Python 3.4 is the current in-development version of Python and that +you have a patch that should also be applied to Python 3.3. To properly port the patch to both versions of Python, you should first apply the patch to -Python 3.2:: +Python 3.3:: - hg update 3.2 + hg update 3.3 hg import --no-commit patch.diff # Compile; run the test suite hg commit -With the patch now committed, you want to merge the patch up into Python 3.3. +With the patch now committed, you want to merge the patch up into Python 3.4. This should be done *before* pushing your changes to hg.python.org, so that the branches are in sync on the public repository. Assuming you are doing all of your work in a single clone, do:: hg update default - hg merge 3.2 + hg merge 3.3 # Fix any conflicts; compile; run the test suite hg commit .. note:: - *If the patch shouldn't be ported* from Python 3.2 to Python 3.3, you must + *If the patch shouldn't be ported* from Python 3.3 to Python 3.4, you must also make it explicit: merge the changes but revert them before committing:: hg update default - hg merge 3.2 + hg merge 3.3 hg revert -ar default hg commit @@ -324,7 +324,7 @@ hg push -This will push changes in both the Python 3.2 and Python 3.3 branches to +This will push changes in both the Python 3.3 and Python 3.4 branches to hg.python.org. @@ -332,7 +332,7 @@ '''''''''''''''''''''''''''''' Let's say you have committed your changes as changeset ``a7df1a869e4a`` -in the 3.2 branch and now want to port it to 2.7. This is simple using +in the 3.3 branch and now want to port it to 2.7. This is simple using the "graft" command, which uses Mercurial's merge functionality to cherry-pick:: @@ -370,9 +370,16 @@ $ hg clone ssh://hg@hg.python.org/cpython py3k * Then clone it to create another local repository which is then used to + checkout branch 3.3:: + + $ hg clone py3k py3.3 + $ cd py3.3 + $ hg update 3.3 + +* Then clone it to create another local repository which is then used to checkout branch 3.2:: - $ hg clone py3k py3.2 + $ hg clone py3.3 py3.2 $ cd py3.2 $ hg update 3.2 @@ -388,11 +395,11 @@ $ cd py2.7 $ hg update 2.7 -Given this arrangement of local repositories, pushing from the ``py3.1`` -repository will update the ``py3.2`` repository, where you can then merge your -3.1 changes into the 3.2 branch. In turn, pushing changes from the ``py3.2`` +Given this arrangement of local repositories, pushing from the ``py3.2`` +repository will update the ``py3.3`` repository, where you can then merge your +3.2 changes into the 3.3 branch. In turn, pushing changes from the ``py3.3`` repository will update the ``py3k`` repository. Finally, once you have -merged (and tested!) your ``3.2`` changes into the ``default`` branch, pushing +merged (and tested!) your ``3.3`` changes into the ``default`` branch, pushing from the ``py3k`` repository will publish your changes in the public repository. @@ -402,6 +409,8 @@ cd ~/py3k hg pull -u + cd ~/py3.3 + hg pull -u cd ~/py3.2 hg pull -u cd ~/py2.7 diff --git a/devcycle.rst b/devcycle.rst --- a/devcycle.rst +++ b/devcycle.rst @@ -40,8 +40,8 @@ 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 -3.2 and 3.3, first fix it in ``3.2`` and then merge ``3.2`` into ``default`` -(which holds the future 3.3). +3.3 and 3.4, first fix it in ``3.3`` and then merge ``3.3`` into ``default`` +(which holds the future 3.4). .. _indevbranch: @@ -54,9 +54,9 @@ changes, performance improvements, bug fixes. As the name indicates, it is the branch :ref:`checked out ` by default by Mercurial. -Once a :ref:`final` release (say, 3.2) is made from the in-development branch, a +Once a :ref:`final` release (say, 3.3) is made from the in-development branch, a new :ref:`maintenance branch ` is created to host all bug fixing -activity for further micro versions (3.2.1, 3.2.2, etc.). +activity for further micro versions (3.3.1, 3.3.2, etc.). .. _maintbranch: @@ -71,13 +71,15 @@ The only changes allowed to occur in a maintenance branch without debate are bug fixes. Also, a general rule for maintenance branches is that compatibility -must not be broken at any point between sibling minor releases (3.1.1, 3.1.2, +must not be broken at any point between sibling minor releases (3.3.1, 3.3.2, etc.). For both rules, only rare exceptions are accepted and **must** be discussed first. When a new maintenance branch is created (after a new *minor version* is -released), the old maintenance branch on that major version (e.g. 3.1.x -after 3.2 gets released) goes into :ref:`security mode `. +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 `, +usually after one last maintenance release at the discretion of the +release manager. .. _secbranch: @@ -97,11 +99,13 @@ Summary ------- -There are 5 open branches right now in the Mercurial repository: +There are 6 open branches right now in the Mercurial repository: -- the ``default`` branch holds the future 3.3 version and descends from ``3.2`` -- the ``3.2`` branch holds bug fixes for future 3.2.x maintenance releases - and descends from ``3.1`` +- 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.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 @@ -258,13 +258,12 @@ Typing ``hg branches`` displays the open branches in your local repository:: $ hg branches - default 68026:f12ef116dd10 - 3.2 68025:cef92ee1a323 - 2.7 68010:8174d00d0797 - 3.1 67955:5be8b695ea86 - 2.6 67287:5e26a860eded - 2.5 65464:e4ecac76e499 - + default 79844:2d53f92ed54c + 2.7 79839:422a0175bbf5 + 3.3 79843:25722e983ada (inactive) + 3.2 79840:d459a9576d6c (inactive) + 3.1 76255:5a6fa1b8767f (inactive) + 2.6 76213:f130ce67387d (inactive) Why are some branches marked "inactive"? ---------------------------------------- @@ -273,9 +272,9 @@ $ hg branches default 68042:8ff33af017ef - 3.2 68039:c17d7772c638 (inactive) + 3.3 68039:c17d7772c638 (inactive) -This means all changesets in the "3.2" branch have been merged into the +This means all changesets in the "3.3" branch have been merged into the "default" branch (or any other branch, if such exists). @@ -308,10 +307,10 @@ $ hg branch default - $ hg update 3.2 + $ hg update 3.3 86 files updated, 0 files merged, 11 files removed, 0 files unresolved $ hg branch - 3.2 + 3.3 Adding the ``-v`` option to ``hg update`` will list all updated files. @@ -327,11 +326,11 @@ Just clone your local repository and update each clone to a different branch:: - $ hg clone cpython py32 + $ hg clone cpython py33 updating to branch default 3434 files updated, 0 files merged, 0 files removed, 0 files unresolved - $ cd py32 - $ hg update 3.2 + $ cd py33 + $ hg update 3.3 86 files updated, 0 files merged, 11 files removed, 0 files unresolved The current branch in a working copy is "sticky": if you pull in some new @@ -935,5 +934,5 @@ message, then it is necessary to identify any Python build directories as auto-load safe. One way to achieve this is to add a line like the following to ``~/.gdbinit`` (edit the specific list of paths as appropriate):: - + add-auto-load-safe-path ~/devel/py3k:~/devel/py32:~/devel/py27 diff --git a/setup.rst b/setup.rst --- a/setup.rst +++ b/setup.rst @@ -42,9 +42,9 @@ If you want a working copy of an already-released version of Python, i.e., a version in :ref:`maintenance mode `, you can update your -working copy. For instance, to update your working copy to Python 3.1, do:: +working copy. For instance, to update your working copy to Python 3.3, do:: - hg update 3.1 + hg update 3.3 You will need to re-compile CPython when you do such an update. diff --git a/triaging.rst b/triaging.rst --- a/triaging.rst +++ b/triaging.rst @@ -125,9 +125,9 @@ Versions '''''''' The known versions of Python that the issue affects and should be fixed for. -Thus if an issue for a new feature is assigned for e.g., Python 3.2 but is not -applied before Python 3.2.0 is released, this field should be updated to say -Python 3.3 as the version and drop Python 3.2. +Thus if an issue for a new feature is assigned for e.g., Python 3.3 but is not +applied before Python 3.3.0 is released, this field should be updated to say +Python 3.4 as the version and drop Python 3.3. Priority '''''''' @@ -170,8 +170,8 @@ The patch attached to the issue is in need of a review. patch There is a patch attached to the issue. -3.2regression - The issue is a regression in 3.2. +3.3regression + The issue is a regression in 3.3. Nosy List '''''''''