From a18e6bd266bddee339e57d70a0121e1ec7e6282a Mon Sep 17 00:00:00 2001 From: Barry Warsaw Date: Thu, 2 Oct 2008 03:10:35 +0000 Subject: [PATCH] The usual post release updates --- pep-0101.txt | 180 +++++++++++++++++++++++++++++---------------------- pep-0361.txt | 7 +- 2 files changed, 107 insertions(+), 80 deletions(-) diff --git a/pep-0101.txt b/pep-0101.txt index c3b98d2c3..3d0118327 100644 --- a/pep-0101.txt +++ b/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 - * WE = Windows: Martin von Loewis - * ME = Mac: Ronald Oussoren + * RM = Release Manager: Barry Warsaw (US/Eastern) + * WE = Windows: Martin von Loewis + * ME = Mac: Ronald Oussoren + * IE = Idle Expert: ?? + * RE = RPM Expert: Sean Reifschneider + + 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 - 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. + 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. + 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@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, - 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 @@ 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 - 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 @@ 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 - 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 @@ 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 - - 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. - When making a major release (e.g., for 2.6), you should branch. - To create a _branch_ (e.g., release26-maint), do the following: + For a final release, the RM may block at this point waiting for + 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 - 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 - 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 @@ 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 . diff --git a/pep-0361.txt b/pep-0361.txt index 9adbb4a94..97f89239b 100644 --- a/pep-0361.txt +++ b/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 - 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`_