Commits

Ned Deily committed 2f682e1 Draft

Issue #16289: Update Developer's Guide for the 3.4 development cycle.
Note that the Development Cycle page should be updated again once
3.2.x moves from maintenance to security mode.

Comments (0)

Files changed (5)

 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.
 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
 
 
    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.
 
 
 ''''''''''''''''''''''''''''''
 
 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::
 
    $ 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
 
    $ 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.
 
 
   cd ~/py3k
   hg pull -u
+  cd ~/py3.3
+  hg pull -u
   cd ~/py3.2
   hg pull -u
   cd ~/py2.7
 
 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:
 changes, performance improvements, bug fixes.  As the name indicates, it
 is the branch :ref:`checked out <checkout>` 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 <maintbranch>` 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:
 
 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 <secbranch>`.
+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>`,
+usually after one last maintenance release at the discretion of the
+release manager.
 
 .. _secbranch:
 
 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``
 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"?
 ----------------------------------------
 
    $ 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).
 
 
 
    $ 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.
 
 
 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
 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
 
 If you want a working copy of an already-released version of Python,
 i.e., a version in :ref:`maintenance mode <maintbranch>`, 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.
 
 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
 ''''''''
     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
 '''''''''