[Python-checkins] r66719 - in peps/trunk: pep-0101.txt pep-0361.txt
barry.warsaw
python-checkins at python.org
Thu Oct 2 05:10:36 CEST 2008
Author: barry.warsaw
Date: Thu Oct 2 05:10:35 2008
New Revision: 66719
Log:
The usual post release updates
Modified:
peps/trunk/pep-0101.txt
peps/trunk/pep-0361.txt
Modified: peps/trunk/pep-0101.txt
==============================================================================
--- peps/trunk/pep-0101.txt (original)
+++ peps/trunk/pep-0101.txt Thu Oct 2 05:10:35 2008
@@ -35,9 +35,20 @@
the designated person performing the release. The roles and their
current experts are:
- * RM = Release Manager: Barry Warsaw
- * WE = Windows: Martin von Loewis
- * ME = Mac: Ronald Oussoren
+ * RM = Release Manager: Barry Warsaw <barry at python.org> (US/Eastern)
+ * WE = Windows: Martin von Loewis <martin at v.loewis.de>
+ * ME = Mac: Ronald Oussoren <ronaldoussoren at mac.com>
+ * IE = Idle Expert: ??
+ * RE = RPM Expert: Sean Reifschneider <jafo at 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 @@
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
- release number is given, it is of the form X.YaZ, e.g. 2.6a3 for
- Python 2.6 alpha 3, where "a" == alpha, "b" == beta, "c" ==
- release candidate.
-
- Final releases are named "releaseXY". The branch tag is
- "releaseXY-maint" because this will point to the long lived
- maintenance branch. The fork tag on the trunk is
- "releaseXY-fork". If a micro release number is used, then we'll
- say X.Y.MaZ.
+ We use the following conventions in the examples below. Where a release
+ number is given, it is of the form X.YaZ, e.g. 2.6a3 for Python 2.6 alpha
+ 3, where "a" == alpha, "b" == beta, "c" == release candidate.
+
+ Final releases are named "releaseXY". The branch tag is "releaseXY-maint"
+ because this will point to the long lived maintenance branch. The fork
+ tag on the trunk is "releaseXY-fork". If a micro release number is used,
+ then we'll 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
- world. This IRC channel is where we've arranged to meet.
+ You probably need to coordinate with other people around the world.
+ This IRC channel is where we've arranged to meet.
___ Impose a check-in freeze by sending email to python-committers at python.org
@@ -87,21 +96,20 @@
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,
- but which won't block a non-final release.
-
- You can make alpha and beta releases with open critical bugs, but you
- may not make a final release with open critical bugs.
+ critical - Important bugs that should be fixed, but which does not block
+ a release.
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
- crticial bugs.
+ you're making a final or candidate release, do the same with any open
+ deferred.
___ Check the stable buildbots.
@@ -109,11 +117,11 @@
(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
- good to go. If you have non-offline red buildbots, you may want to hold
- up the release until they are fixed. Review the problems and use your
- judgement, taking into account whether you are making an alpha, beta, or
- final release.
+ they can be restarted). If what remains are (mostly) green buildbots,
+ you're good to go. If you have non-offline red buildbots, you may want
+ to hold up the release until they are fixed. Review the problems and
+ use your judgement, taking into account whether you are making an alpha,
+ beta, or final release.
___ Bump version numbers via the release script.
@@ -124,10 +132,10 @@
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
- years, this has become easier as the community is responsible for most
- of the content of this file. You should only need to review the text
- for sanity, and update the release date with today's date.
+ It is important to update the Misc/NEWS file, however in recent years,
+ this has become easier as the community is responsible for most of the
+ content of this file. You should only need to review the text for
+ 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 @@
___ 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
-
- 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.
+ ___ Tag the release for X.YaZ
.../sandbox/release/release.py --tag X.YaZ
- Practically speaking, we tag and branch just before making the
- release. Branching too early causes too much merging work.
+ ___ Send an email to the Experts so that they can build the binaries.
+
+ For a final release, the RM may block at this point waiting for
+ confirmation from the Experts.
- When making a major release (e.g., for 2.6), you should branch.
- To create a _branch_ (e.g., release26-maint), do the following:
+ ___ If this is a final major release, branch the tree for X.YaZ
- .../sandbox/release/release.py --branch X.Y.Z
+ 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 @@
___ cd release26-maint # cd into the branch directory.
- ___ XXX If this is a release candidate, mail Sean <jafo at 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 @@
___ 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 @@
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 @@
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 @@
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 @@
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
- sure they are world readable. They should also be group writable,
- and group-owned by webmaster.
+ ___ Move the release .tgz, tar.bz2, and .msi files into place
+
+ 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 @@
___ 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 @@
python-announce at python.org
python-dev at 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 @@
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>.
Modified: peps/trunk/pep-0361.txt
==============================================================================
--- peps/trunk/pep-0361.txt (original)
+++ peps/trunk/pep-0361.txt Thu Oct 2 05:10:35 2008
@@ -59,9 +59,10 @@
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
- Oct 01 2008: Python 2.6final and 3.0rc2 planned
- Oct 15 2008: Python 3.0final planned
+ Sep 17 2008: Python 2.6rc2 and 3.0rc1 released
+ Oct 01 2008: Python 2.6 final released
+ ??? ?? 2008: Python 3.0rc2 planned
+ ??? ?? 2008: Python 3.0final planned
See the public `Google calendar`_
More information about the Python-checkins
mailing list