iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

The usual post release updates

This commit is contained in:
Barry Warsaw 2008-10-02 03:10:35 +00:00
parent 21fcdfb2c2
commit a18e6bd266
2 changed files with 107 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

180
pep-0101.txt
View File

@ -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 <barry@python.org> (US/Eastern)
* WE = Windows: Martin von Loewis <martin@v.loewis.de>
* 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
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 <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
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 <wink>.

7
pep-0361.txt
View File

@ -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`_