[Python-checkins] devguide: Issue #16289: Update Developer's Guide for the 3.4 development cycle.
ned.deily
python-checkins at python.org
Sat Oct 20 23:05:07 CEST 2012
http://hg.python.org/devguide/rev/2f682e133960
changeset: 560:2f682e133960
user: Ned Deily <nad at acm.org>
date: Sat Oct 20 14:04:19 2012 -0700
summary:
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.
files:
committing.rst | 41 +++++++++++++++++++++++--------------
devcycle.rst | 26 +++++++++++++----------
faq.rst | 29 ++++++++++++-------------
setup.rst | 4 +-
triaging.rst | 10 ++++----
5 files changed, 61 insertions(+), 49 deletions(-)
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 <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:
@@ -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 <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:
@@ -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 <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.
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
'''''''''
--
Repository URL: http://hg.python.org/devguide
More information about the Python-checkins
mailing list