Update devguide for 3.6.0b1 and start of 3.7.

Author: ned-deily

committing.rst

@@ -413,11 +413,16 @@ as follow::
    $ cd ../3.5
    $ hg up
    $ hg graft 2.7
-   $ # switch to 3.x, merge, commit, and push everything
-   $ cd ../3.x
+   $ # switch to 3.6, merge and commit
+   $ cd ../3.6
    $ hg up
    $ hg merge 3.5
    $ hg ci -m '#12345: merge with 3.5.'
+   $ # switch to 3.x, merge, commit, and push everything
+   $ cd ../3.x
+   $ hg up
+   $ hg merge 3.6
+   $ hg ci -m '#12345: merge with 3.6.'
    $ hg push
 
 Unless noted otherwise, the rest of the page will assume you are using the
@@ -458,25 +463,25 @@ Python version.
 Merging between different branches (within the same major version)
 ------------------------------------------------------------------
 
-Assume that Python 3.6 is the current in-development version of Python and that
-you have a patch that should also be applied to Python 3.5.  To properly port
+Assume that Python 3.7 is the current in-development version of Python and that
+you have a patch that should also be applied to Python 3.6.  To properly port
 the patch to both versions of Python, you should first apply the patch to
-Python 3.5::
+Python 3.6::
 
-   cd 3.5
+   cd 3.6
    hg import --no-commit patch.diff
    # Compile; run the test suite
    hg ci -m '#12345: fix some issue.'
 
-Then you can switch to the ``3.5`` clone, merge, run the tests and commit::
+Then you can switch to the ``3.7`` clone, merge, run the tests and commit::
 
-   cd ../3.6
-   hg merge 3.5
+   cd ../3.7
+   hg merge 3.6
    # Fix any conflicts (e.g. ``hg revert -r default Misc/NEWS``); compile; run the test suite
-   hg ci -m '#12345: merge with 3.5.'
+   hg ci -m '#12345: merge with 3.6.'
 
 If you are not using the share extension, you will need to use
-``hg pull ../3.5`` before being able to merge.
+``hg pull ../3.6`` before being able to merge.
 
 .. note::
    Even when porting an already committed patch, you should *still* check the
@@ -488,29 +493,29 @@ If you are not using the share extension, you will need to use
 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.5``.
+Assume you just committed something on ``2.7``, and want to port it to ``3.6``.
 You can use ``hg graft`` as follow::
 
-   cd ../3.5
+   cd ../3.6
    hg graft 2.7
 
-This will port the latest changeset committed in the 2.7 clone to the 3.5 clone.
+This will port the latest changeset committed in the 2.7 clone to the 3.6 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
 also graft changesets from 3.x to 2.7.
 
 On older version of Mercurial where ``hg graft`` is not available, you can use::
 
-    cd ../3.5
+    cd ../3.6
     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.5``.  This is convenient
+A third option is to apply manually the patch on ``3.6``.  This is convenient
 when there are too many differences with ``2.7`` or when there is already a
-specific patch for ``3.5``.
+specific patch for ``3.6``.
 
 .. warning::
    Never use ``hg merge`` to port changes between 2.x and 3.x (or vice versa).

devcycle.rst

@@ -31,17 +31,17 @@ Branches
 ''''''''
 
 There is a branch for each *feature version*, whether released or not (e.g.
-2.7, 3.5).  Development is handled separately for Python 2 and Python 3:
+2.7, 3.6).  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.5`` branch is a
-descendant of the ``3.4`` branch.
+descendant of the previous feature version: for example, the ``3.6`` branch is a
+descendant of the ``3.5`` 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
-3.5 and 3.6, first fix it in ``3.5`` and then merge ``3.5`` into ``default``
-(which holds the future 3.6).
+3.6 and 3.7, first fix it in ``3.6`` and then merge ``3.6`` into ``default``
+(which holds the future 3.7).
 
 
 .. _indevbranch:
@@ -61,11 +61,11 @@ activity for further micro versions (3.3.1, 3.3.2, etc.).
 For versions 3.4 and before, this was conventionally done when the final
 release was cut (for example, 3.4.0 final).
 
-.. note::
-  For the 3.5 release we're trying something new. We're creating the 3.5
-  maintenance branch at the time we enter beta (3.5.0 beta 1).  This will
-  allow feature development for 3.6 to occur alongside the beta and release
-  candidate stabilization periods for 3.5.
+Starting with the 3.5 release, we create the release maintenance branch
+(e.g. 3.5) at the time we enter beta (3.5.0 beta 1).  This allows
+feature development for the release 3.n+1 to occur within the default
+branch alongside the beta and release candidate stabilization periods
+for release 3.n.
 
 .. _maintbranch:
 
@@ -117,10 +117,12 @@ security patches have been applied to the branch.
 Summary
 -------
 
-There are 6 open branches right now in the Mercurial repository:
+There are 7 open branches right now in the Mercurial repository:
 
-- the ``default`` branch holds the future 3.6 version and descends from ``3.5``
+- the ``default`` branch holds the future 3.7 version and descends from ``3.6``
   (RM: Ned Deily)
+- the ``3.6`` branch holds bug fixes for 3.6.0 and future 3.6.x maintenance releases
+  and descends from ``3.5`` (RM: Ned Deily)
 - the ``3.5`` branch holds bug fixes for future 3.5.x maintenance releases
   and descends from ``3.4`` (RM: Larry Hastings)
 - the ``3.4`` branch holds security fixes for future 3.4.x security releases
@@ -195,17 +197,6 @@ You **cannot** skip the peer review during an RC, no matter how small! Even if
 it is a simple copy-and-paste change, **everything** requires peer review from
 a core developer.
 
-.. note::
-  For the 3.5 release we're trying something new.  At the point that we reach 3.5.0
-  release candidate 1, the official release branch will no longer be hosted at
-  ``hg.python.org``.  Instead, 3.5.0 rc 1 through final will be hosted
-  by the 3.5 release manager on bitbucket.
-
-  Bugfixes for 3.5 should still be checked in to the 3.5 branch.  However, if the
-  core developer responsible for the bugfix feels it should be merged into 3.5.0, they
-  will need to create a bitbucket "pull request" for this change.  Any bugfixes not
-  merged into 3.5.0 in this way will be automatically shipped with 3.5.1.
-
 .. _final:
 
 Final

faq.rst

@@ -318,10 +318,10 @@ Simply use ``hg update`` to checkout another branch in the current directory::
 
    $ hg branch
    default
-   $ hg update 3.5
+   $ hg update 3.6
    86 files updated, 0 files merged, 11 files removed, 0 files unresolved
    $ hg branch
-   3.5
+   3.6
 
 Adding the ``-v`` option to ``hg update`` will list all updated files.
 
@@ -343,11 +343,11 @@ There are two ways:
 
 If you want to use the second way, you can do::
 
-   $ hg clone cpython py35
+   $ hg clone cpython py36
    updating to branch default
    3434 files updated, 0 files merged, 0 files removed, 0 files unresolved
    $ cd py35
-   $ hg update 3.5
+   $ hg update 3.6
    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
@@ -796,14 +796,14 @@ You can also use ``hg resolve -am`` to mark all the conflicts as resolved.
 How do I make a null merge?
 '''''''''''''''''''''''''''
 
-If you committed something (e.g. on 3.5) that shouldn't be ported on newer
+If you committed something (e.g. on 3.6) that shouldn't be ported on newer
 branches (e.g. on default), you have to do a *null merge*::
 
    cd 3.x
-   hg merge 3.5
+   hg merge 3.6
    hg revert -ar default
    hg resolve -am  # needed only if the merge created conflicts
-   hg ci -m '#12345: null merge with 3.5.'
+   hg ci -m '#12345: null merge with 3.6.'
 
 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
@@ -842,10 +842,10 @@ a lot easier.
 
 If more than one branch has multiple heads, you have to repeat these steps for
 each branch.  Since this creates new changesets, you will also have to
-:ref:`merge them between branches <branch-merge>`.  For example, if both ``3.5``
-and ``default`` have multiple heads, you should first merge heads in ``3.5``,
-then merge heads in ``default``, and finally merge ``3.5`` with ``default``
-using ``hg merge 3.5`` as usual.
+:ref:`merge them between branches <branch-merge>`.  For example, if both ``3.6``
+and ``default`` have multiple heads, you should first merge heads in ``3.6``,
+then merge heads in ``default``, and finally merge ``3.6`` with ``default``
+using ``hg merge 3.6`` as usual.
 
 In order to avoid this, you should *always remember to pull and update before
 committing*.

index.rst

@@ -66,7 +66,9 @@ Status of Python branches
 +------------------+--------------+-------------+----------------+----------------+----------------------------------------------------------------------------+
 | Branch           | Schedule     | Status      | First release  | End-of-life    | Comment                                                                    |
 +==================+==============+=============+================+================+============================================================================+
-| default          | :pep:`494`   | features    | *2016-12-16*   | *2021-12-16*   | The default branch is currently the future version Python 3.6.             |
+| default          | *TBD*        | features    | *TBD*          | *TBD*          | The default branch is currently the future version Python 3.7.             |
++------------------+--------------+-------------+----------------+----------------+----------------------------------------------------------------------------+
+| 3.6              | :pep:`494`   | bugfix      | *2016-12-16*   | *2021-12-16*   | For the beta and rc phases of the future 3.6.0, then maintenance for 3.6.x |
 +------------------+--------------+-------------+----------------+----------------+----------------------------------------------------------------------------+
 | 3.5              | :pep:`478`   | bugfix      | 2015-09-13     | *2020-09-13*   |                                                                            |
 +------------------+--------------+-------------+----------------+----------------+----------------------------------------------------------------------------+