The usual post release updates

pep-0101.txt

@@ -35,9 +35,20 @@ How to Make A Release
     the designated person performing the release.  The roles and their
     current experts are:
 
-        * RM = Release Manager: Barry Warsaw
+    * RM = Release Manager: Barry Warsaw <barry@python.org> (US/Eastern)
-        * WE = Windows: Martin von Loewis
+    * WE = Windows: Martin von Loewis <martin@v.loewis.de>
-        * ME = Mac: Ronald Oussoren
+    * ME = Mac: Ronald Oussoren <ronaldoussoren@mac.com>
+    * IE = Idle Expert: ??
+    * RE = RPM Expert: Sean Reifschneider <jafo@tummy.com>
+
+    NOTE: It is highly recommended that the RM contact the Experts the day
+          before the release.  Because the world is round and everyone lives
+          in different timezones, the RM must ensure that the release tag is
+          created in enough time for the Experts to cut binary releases.
+
+          IT IS HIGHLY RECOMMENDED THAT YOU AT LEAST TAG THE TREE 24 HOURS
+          BEFORE A FINAL RELEASE.  This will give the Experts enough time to
+          do their bits before the announcement goes out.
 
     XXX: We should include a dependency graph to illustrate the steps
     that can be taken in parallel, or those that depend on other
@@ -45,28 +56,26 @@ How to Make A Release
 
     As much as possible, the release steps are automated and guided by the
     release script, which is available in the Python sandbox.  The release
-    script is currently being maintained by the RM:
+    script is currently being maintained here:
 
         http://svn.python.org/view/sandbox/trunk/release/
 
-    We use the following conventions in the examples below.  Where a
+    We use the following conventions in the examples below.  Where a release
-    release number is given, it is of the form X.YaZ, e.g. 2.6a3 for
+    number is given, it is of the form X.YaZ, e.g. 2.6a3 for Python 2.6 alpha
-    Python 2.6 alpha 3, where "a" == alpha, "b" == beta, "c" ==
+    3, where "a" == alpha, "b" == beta, "c" == release candidate.
-    release candidate.
 
-    Final releases are named "releaseXY".  The branch tag is
+    Final releases are named "releaseXY".  The branch tag is "releaseXY-maint"
-    "releaseXY-maint" because this will point to the long lived
+    because this will point to the long lived maintenance branch.  The fork
-    maintenance branch.  The fork tag on the trunk is
+    tag on the trunk is "releaseXY-fork".  If a micro release number is used,
-    "releaseXY-fork".  If a micro release number is used, then we'll
+    then we'll say X.Y.MaZ.
-    say X.Y.MaZ.
 
     This helps by performing several automatic editing steps, and guides you
     to perform some manual editing steps.
 
   ___ Log into irc.freenode.net and join the #python-dev channel.
 
-      You probably need to coordinate with other people around the
+      You probably need to coordinate with other people around the world.
-      world.  This IRC channel is where we've arranged to meet.
+      This IRC channel is where we've arranged to meet.
 
   ___ Impose a check-in freeze by sending email to python-committers@python.org
 
@@ -87,21 +96,20 @@ How to Make A Release
       release you're making; here are the relevant definitions:
 
       release blocker - Stops the release dead in its tracks.  You may not
-                        make a release with any open blocker bugs.
+                        make any release with any open release blocker bugs.
 
       deferred blocker - Doesn't block this release, but it will block a
-                         future release.
+                         future release.  You many not make a final or
+                         candidate release with any open deferred blocker
+                         bugs.
 
-      critical - Important bugs that should be fixed before the next release,
+      critical - Important bugs that should be fixed, but which does not block
-                 but which won't block a non-final release.
+                 a release.
-
-      You can make alpha and beta releases with open critical bugs, but you
-      may not make a final release with open critical bugs.
 
       Review the release blockers and either resolve them, bump them down to
       deferred, or stop the release and ask for community assistance.  If
-      you're making a final release, do the same with any open deferred and
+      you're making a final or candidate release, do the same with any open
-      crticial bugs.
+      deferred.
 
   ___ Check the stable buildbots.
 
@@ -109,11 +117,11 @@ How to Make A Release
 
       (the trailing slash is required).  Look at the buildbots for the release
       you're making.  Ignore any that are offline (or inform the community so
-      they can be restarted).  If what remains are green buildbots, you're
+      they can be restarted).  If what remains are (mostly) green buildbots,
-      good to go.  If you have non-offline red buildbots, you may want to hold
+      you're good to go.  If you have non-offline red buildbots, you may want
-      up the release until they are fixed.  Review the problems and use your
+      to hold up the release until they are fixed.  Review the problems and
-      judgement, taking into account whether you are making an alpha, beta, or
+      use your judgement, taking into account whether you are making an alpha,
-      final release.
+      beta, or final release.
 
   ___ Bump version numbers via the release script.
 
@@ -124,10 +132,10 @@ How to Make A Release
       set up correctly, release.py will pop up editor windows with the files
       you need to edit.
 
-      Most importantly is to update the Misc/NEWS file, however in recent
+      It is important to update the Misc/NEWS file, however in recent years,
-      years, this has become easier as the community is responsible for most
+      this has become easier as the community is responsible for most of the
-      of the content of this file.  You should only need to review the text
+      content of this file.  You should only need to review the text for
-      for sanity, and update the release date with today's date.
+      sanity, and update the release date with today's date.
 
       If the minor (middle) digit of the version number changes, you will be
       prompted to update some additional files:
@@ -166,29 +174,28 @@ How to Make A Release
   ___ Check with the IDLE maintainer to be sure that
       Lib/idlelib/NEWS.txt has been similarly updated.
 
-      (XXX Who is the IE (i.e. Idle Expert)?
-
   ___ For a final release, edit the first paragraph of
       Doc/whatsnew/X.Y.rst to include the actual release date; e.g. "Python
       2.5 was released on August 1, 2003."  There's no need to edit this for
       alpha or beta releases.  Note that Andrew Kuchling often takes care of
       this.
 
-  ___ Tag and/or branch the tree for release X.YaZ
+  ___ Tag the release for X.YaZ
-
-      If you're releasing an alpha/beta/release candidate, you will just tag
-      the tree.  If you are releasing a final release, you will both tag the
-      trunk and create the long-lived maintenance branch.
 
       .../sandbox/release/release.py --tag X.YaZ
 
-      Practically speaking, we tag and branch just before making the
+  ___ Send an email to the Experts so that they can build the binaries.
-      release.  Branching too early causes too much merging work.
 
-      When making a major release (e.g., for 2.6), you should branch.
+      For a final release, the RM may block at this point waiting for
-      To create a _branch_ (e.g., release26-maint), do the following:
+      confirmation from the Experts.
 
-      .../sandbox/release/release.py --branch X.Y.Z
+  ___ If this is a final major release, branch the tree for X.YaZ
+
+      When making a major release (e.g., for 2.6), you must create the
+      long-lived maintenance branch.  To create a _branch_ (e.g.,
+      release26-maint), do the following:
+
+      .../sandbox/release/release.py --branch X.Y
 
       ___ If you just made the release branch, check out a clean version
           into a new directory.  You'll be doing a lot of work in this
@@ -200,9 +207,6 @@ How to Make A Release
 
       ___ cd release26-maint  # cd into the branch directory.
 
-  ___ XXX If this is a release candidate, mail Sean <jafo@tummy.com>
-      noting the impending release, so that RPMs can be built and tested.
-
   ___ XXX The WE builds the Windows helpfile, using (in Doc/) either
 
         $ make htmlhelp   (on Unix)
@@ -250,7 +254,7 @@ How to Make A Release
   ___ Time to build the source tarball.  If you created a branch, be
       sure to cd to your working directory for the branch.  E.g.
 
-      % cd .../python-26
+      % cd .../python26
 
   ___ Do a "svn update ; svn status" in this directory.
 
@@ -258,9 +262,12 @@ How to Make A Release
       changes in your working directory, but you may pick up some of the
       expert's last minute changes.
 
-  ___ If you've seen updates to existing files, update the svn tag:
+  ___ If you've seen updates to existing files, update the branches.
 
-      .../sandbox/release/release.py --tag X.YaZ
+      ___ Delete the old tag branch and re-tag the tree
+      ___ Delete the maintenance branch and re-branch the trunk.
+
+      This should be rare and indicates a breakdown in the process.
 
   ___ Use the release script to create the gzip and bz2 tarballs, md5
       checksums, and gpg signature files.
@@ -269,6 +276,13 @@ How to Make A Release
 
       This will leave all the relevant files in a subdirectory called 'dist'.
 
+  ___ scp the files to your home directory on dinsdale.python.org.
+
+      While you're waiting for the files to finish uploading, you can continue
+      on with the remaining tasks.  You can also ask folks on #python-dev to
+      download the files as they finish uploading so that they can test them
+      on their platforms as well.
+
   ___ Now you want to perform the very important step of checking the
       tarball you just created, to make sure a completely clean,
       virgin build passes the regression test.  Here are the best
@@ -308,18 +322,13 @@ How to Make A Release
       To ensure that the regression test suite passes.  If not, you
       screwed up somewhere!
 
-  ___ Upload the tar files to dinsdale.python.org using scp.
-
-  ___ Now we're waiting for the scp to dinsdale to finish.  Da de da,
-      da de dum, hmm, hmm, dum de dum.
-
   ___ Now you need to go to dinsdale.python.org and move all the files
       in place over there.  Our policy is that every Python version gets its
       own directory, but each directory may contain several releases.  We keep
       all old releases, moving them into a "prev" subdirectory when we have a
       new release.
 
-      So, there's a directory called "2.6" which contains Python-2.5a2.exe and
+      So, there's a directory called "2.6" which contains Python-2.6a2.exe and
       Python-2.6a2.tgz, along with a "prev" subdirectory containing
       Python-2.6a1.msi, Python-2.6a1.tgz, Python-2.6a1.tar.bz2, etc.
 
@@ -335,9 +344,10 @@ How to Make A Release
           directory, You'll move everything in there when the final release
           comes out.
 
-      ___ Move the .tgz, tar.bz2, and .msi files to this directory.  Make
+      ___ Move the release .tgz, tar.bz2, and .msi files into place
-          sure they are world readable.  They should also be group writable,
+
-          and group-owned by webmaster.
+          Make sure they are world readable.  They should also be group
+          writable, and group-owned by webmaster.
 
       ___ md5sum the files and make sure they got uploaded intact.
 
@@ -377,6 +387,38 @@ How to Make A Release
   ___ Add a news section item to the front page by editing newsindex.yml.  The
       format should be pretty self evident.
 
+  ___ If this is a final release...
+
+      ___ update the 'Quick Links' section on the front page.  Edit the
+          top-level `content.ht` file.
+
+      ___ update the download page, editing `download/content.ht`
+
+      ___ edit the previous release's last release content.ht page to point to
+          the new release.
+
+      ___ Mention the release as the most recent stable one in
+          `doc/faq/general.ht` (section "How stable is Python?")
+
+      ___ update `doc/content.ht` to indicate the new current documentation
+          version, and remove the current version from any 'in development'
+          section.
+
+      ___ add the new version to `doc/version/content.ht`
+
+      ___ Make the last change to the documentation area on python.org.
+
+          The "current" symlink needs to be updated if this release is the
+          highest-versioned release.  Log in to dinsdale.python.org, and
+          update a symlink in the doc/ tree:
+
+            # on dinsdale:
+            $ cd /data/ftp.python.org/pub/www.python.org/doc/
+            $ rm current && ln -s $VERSION current
+
+          XXX This does not seem complete.  I still don't really understand
+          how all the documentation stuff hangs together.
+
   ___ Edit download/releases/content.ht to update the version numbers for
       this release.  There are a bunch of places you need to touch:
 
@@ -412,22 +454,6 @@ How to Make A Release
       python-announce@python.org
       python-dev@python.org
 
-  ___ XXX Mention the release as the most recent stable one in
-      pydotorg:doc/faq/general.ht (section "How stable is
-      Python?")
-
-  ___ XXX Make the last change to the documentation area on
-      python.org.  (Remember those from the documentation items above?
-      It's time now.)
-
-      The "current" symlink needs to be updated if this release is the
-      highest-versioned release.  Log in to dinsdale.python.org, and
-      update a symlink in the doc/ tree:
-
-        # on dinsdale:
-        $ cd /data/ftp.python.org/pub/www.python.org/doc/
-        $ rm current && ln -s $VERSION current
-
   Now it's time to do some cleaning up.  These steps are very important!
 
   ___ If you made a non-maintenance branch, be sure to merge it into
@@ -522,7 +548,7 @@ Final Release Notes
     three major releases: Windows, Mac, and source.  So we add this
     extra step to the release process for a final release:
 
-    ___ Hold up the final release until the WE and ME approve, or until we
+    ___ Hold up the final release until the Experts approve, or until we
         lose patience <wink>.
 
 

pep-0361.txt

@@ -59,9 +59,10 @@ Release Schedule
         Jul 17 2008: Python 2.6b2 and 3.0b2 are released
         Aug 20 2008: Python 2.6b3 and 3.0b3 are released
         Sep 12 2008: Python 2.6rc1 is released
-        Sep 17 2008: Python 2.6rc2 and 3.0rc1 planned
+        Sep 17 2008: Python 2.6rc2 and 3.0rc1 released
-        Oct 01 2008: Python 2.6final and 3.0rc2 planned
+        Oct 01 2008: Python 2.6 final released
-        Oct 15 2008: Python 3.0final planned
+        ??? ?? 2008: Python 3.0rc2 planned
+        ??? ?? 2008: Python 3.0final planned
 
         See the public `Google calendar`_