Document how to handle cherry-picks for final or rc2+ releases

pep-0101.txt

@@ -85,7 +85,8 @@ There are several types of releases you will need to make.  These include:
 
 * ``alpha``
 * ``beta``
-* ``release candidate``
+* ``release candidate 1``
+* ``release candidate 2+``
 * ``final``
 * ``new branch``
 * ``begin bugfix mode``
@@ -210,6 +211,12 @@ to perform some manual editing steps.
   tagging the release, and you will use it to share with the other experts
   for making the binaries.
 
+  For a **final** or **release candidate 2+** release, create a release
+  engineering branch starting from the most recent release candidate tag,
+  i.e. ``v3.8.0rc1``. You will then cherry-pick changes from the standard
+  release branch as necessary into the release engineering branch and
+  then proceed as usual.
+
 - Notify all committers by sending email to python-committers@python.org.
 
   Since we're now working with a distributed version control system, there
@@ -555,6 +562,21 @@ the main repo.
 
     $ .../release-tools/release.py --done X.Y.ZaN
 
+- For a **final** or **release candidate 2+** release, you may need to
+  do some post-merge cleanup.  Check the top-level ``README.rst``
+  and ``include/patchlevel.h`` files to ensure they now reflect
+  the desired post-release values for on-going development.
+  The patchlevel should be the release tag with a `+`.
+  Also, if you cherry-picked changes from the standard release
+  branch into the release engineering branch for this release,
+  you will now need to manual remove each blurb entry from
+  the ``Misc/NEWS.d/next`` directory that was cherry-picked
+  into the release you are working on since that blurb entry
+  is now captured in the merged x.y.z.rst fils for the new
+  release.  Otherwise, the blurb entry will appear twice in
+  the `changelog.html` file, once under `Python next` and again
+  under `x.y.z`.
+
 - Review and commit these changes::
 
     $ git commit -m 'Post release updates'