658 lines
26 KiB
Plaintext
658 lines
26 KiB
Plaintext
PEP: 101
|
||
Title: Doing Python Releases 101
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: barry@python.org (Barry Warsaw), guido@python.org (Guido van Rossum)
|
||
Status: Active
|
||
Type: Informational
|
||
Created: 22-Aug-2001
|
||
Post-History:
|
||
|
||
|
||
Abstract
|
||
|
||
Making a Python release is a thrilling and crazy process. You've heard
|
||
the expression "herding cats"? Imagine trying to also saddle those
|
||
purring little creatures up, and ride them into town, with some of their
|
||
buddies firmly attached to your bare back, anchored by newly sharpened
|
||
claws. At least they're cute, you remind yourself.
|
||
|
||
Actually, no that's a slight exaggeration <wink>. The Python release
|
||
process has steadily improved over the years and now, with the help of our
|
||
amazing community, is really not too difficult. This PEP attempts to
|
||
collect, in one place, all the steps needed to make a Python release. It
|
||
is organized as a recipe and you can actually print this out and check
|
||
items off as you complete them.
|
||
|
||
Things You'll Need
|
||
|
||
As a release manager there are a lot of resources you'll need to access.
|
||
Here's a hopefully-complete list.
|
||
|
||
* A GPG key.
|
||
|
||
Python releases are digitally signed with GPG; you'll need a key,
|
||
which hopefully will be on the "web of trust" with at least one of
|
||
the other release managers.
|
||
|
||
* Access to ``dl-files.psf.io``, the server that hosts download files.
|
||
You'll be uploading files directly here.
|
||
|
||
* Shell access to ``hg.python.org``, the Python Mercurial host. You'll
|
||
have to adapt repository configuration there.
|
||
|
||
* Write access to the website SVN repository
|
||
|
||
Instructions here:
|
||
|
||
http://www.python.org/dev/pydotorg/website/
|
||
|
||
* Write access to the PEP repository.
|
||
|
||
If you're reading this, you probably already have this--the first
|
||
task of any release manager is to draft the release schedule. But
|
||
in case you just signed up... sucker! I mean, uh, congratulations!
|
||
|
||
* Posting access to http://blog.python.org, a Blogger-hosted weblog.
|
||
The RSS feed from this blog is used for the 'Python News' section
|
||
on www.python.org.
|
||
|
||
How to Make A Release
|
||
|
||
Here are the steps taken to make a Python release. Some steps are more
|
||
fuzzy than others because there's little that can be automated (e.g.
|
||
writing the NEWS entries). Where a step is usually performed by An
|
||
Expert, the role of that expert is given. Otherwise, assume the step is
|
||
done by the Release Manager (RM), the designated person performing the
|
||
release. The roles and their current experts are:
|
||
|
||
* RM = Release Manager: Larry Hastings <larry@hastings.org> (US)
|
||
* WE = Windows: Martin von Loewis <martin@v.loewis.de> (Central Europe) and Steve Dower <steve.dower@microsoft.com>
|
||
* ME = Mac: Ned Deily <nad@acm.org> (US)
|
||
* DE = Docs: Georg Brandl <georg@python.org> (Central Europe)
|
||
* IE = Idle Expert: ??
|
||
|
||
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.
|
||
|
||
You should not make the release public (by updating the website and
|
||
sending announcements) before all experts have updated their bits.
|
||
In rare cases where the expert for Windows or Mac is MIA, you may add
|
||
a message "(Platform) binaries will be provided shortly" and proceed.
|
||
|
||
XXX: We should include a dependency graph to illustrate the steps that can
|
||
be taken in parallel, or those that depend on other steps.
|
||
|
||
As much as possible, the release steps are automated and guided by the
|
||
release script, which is available in a separate repository:
|
||
|
||
http://hg.python.org/release/
|
||
|
||
We use the following conventions in the examples below. Where a release
|
||
number is given, it is of the form X.Y.ZaN, e.g. 3.3.0a3 for Python 3.3.0
|
||
alpha 3, where "a" == alpha, "b" == beta, "rc" == release candidate.
|
||
|
||
Release tags are named "vX.Y.ZaN". The branch name for minor release
|
||
maintenance branches is "X.Y".
|
||
|
||
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.
|
||
|
||
___ Check to see if there are any showstopper bugs.
|
||
|
||
Go to http://bugs.python.org and look for any open bugs that can block
|
||
this release. You're looking at the Priority of the open bugs for the
|
||
release you're making; here are the relevant definitions:
|
||
|
||
release blocker - Stops the release dead in its tracks. You may not
|
||
make any release with any open release blocker bugs.
|
||
|
||
deferred blocker - Doesn't block this release, but it will block a
|
||
future release. You may not make a final or
|
||
candidate release with any open deferred blocker
|
||
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 or candidate release, do the same with any open
|
||
deferred.
|
||
|
||
___ Check the stable buildbots.
|
||
|
||
Go to http://www.python.org/dev/buildbot/stable/
|
||
|
||
(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 (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.
|
||
|
||
___ Make a release clone.
|
||
|
||
Create a local clone of the cpython repository (called the "release
|
||
clone" from now on).
|
||
|
||
Also clone the repo at http://hg.python.org/cpython using the
|
||
server-side clone feature. The name of the new clone should preferably
|
||
have a "releasing/" prefix. The other experts will use the release
|
||
clone for making the binaries, so it is important that they have access
|
||
to it!
|
||
|
||
It's best to set up your local release clone to push to the remote
|
||
release clone by default (by editing .hg/hgrc to that effect).
|
||
|
||
___ Notify all committers by sending email to python-committers@python.org.
|
||
|
||
Since we're now working with a distributed version control system, there
|
||
is no need to stop everyone from pushing to the main repo; you'll just
|
||
work in your own clone. Therefore, there won't be any checkin freezes.
|
||
|
||
However, all committers should know the point at which your release
|
||
clone was made, as later commits won't make it into the release without
|
||
extra effort.
|
||
|
||
___ Make sure the current branch of your release clone is the branch you
|
||
want to release from.
|
||
|
||
___ Regenerate Lib/pydoc-topics.py.
|
||
|
||
cd to the Doc directory and type ``make pydoc-topics``. Then copy
|
||
``build/pydoc-topics/topics.py`` to ``../Lib/pydoc_data/topics.py``.
|
||
|
||
___ Check the docs for markup errors.
|
||
|
||
In the Doc directory, type ``make suspicious``. If any markup errors
|
||
are found, fix them.
|
||
|
||
___ Commit any changes to pydoc_topics.py and the doc sources.
|
||
|
||
___ Make sure the SOURCE_URI in ``Doc/tools/sphinxext/pyspecific.py``
|
||
points to the right branch in the hg repository (or ``default`` for
|
||
unstable releases of the default branch).
|
||
|
||
___ Bump version numbers via the release script.
|
||
|
||
$ .../release/release.py --bump X.Y.ZaN
|
||
|
||
This automates updating various release numbers, but you will have to
|
||
modify a few files manually. If your $EDITOR environment variable is
|
||
set up correctly, release.py will pop up editor windows with the files
|
||
you need to edit.
|
||
|
||
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.
|
||
|
||
___ Make sure all changes have been committed. (``release.py --bump``
|
||
doesn't check in its changes for you.)
|
||
|
||
___ Check the years on the copyright notice. If the last release
|
||
was some time last year, add the current year to the copyright
|
||
notice in several places:
|
||
|
||
___ README
|
||
___ LICENSE (make sure to change on trunk and the branch)
|
||
___ Python/getcopyright.c
|
||
___ Doc/README.txt (at the end)
|
||
___ Doc/copyright.rst
|
||
___ Doc/license.rst
|
||
___ PC/python_nt.rc sets up the DLL version resource for Windows
|
||
(displayed when you right-click on the DLL and select
|
||
Properties).
|
||
|
||
___ Check with the IE (if there is one <wink>) to be sure that
|
||
Lib/idlelib/NEWS.txt has been similarly updated.
|
||
|
||
___ For a final major 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 the release for X.Y.ZaN.
|
||
|
||
$ .../release/release.py --tag X.Y.ZaN
|
||
|
||
NOTE: when forward, i.e. "null" merging your changes to newer branches,
|
||
e.g. 2.6 -> 2.7, do *not* revert your changes to the .hgtags file or you
|
||
will not be able to run the --export command below. Revert everything
|
||
else but leave .hgtags alone.
|
||
|
||
___ If this is a final major release, branch the tree for X.Y.
|
||
|
||
When making a major release (e.g., for 3.2), you must create the
|
||
long-lived maintenance branch.
|
||
|
||
___ Note down the current revision ID of the tree.
|
||
|
||
$ hg identify
|
||
|
||
___ First, set the original trunk up to be the next release.
|
||
|
||
$ .../release/release.py --bump 3.3a0
|
||
|
||
___ Edit all version references in the README
|
||
|
||
___ Move any historical "what's new" entries from Misc/NEWS to
|
||
Misc/HISTORY.
|
||
|
||
___ Edit Doc/tutorial/interpreter.rst (2 references to '[Pp]ython3x',
|
||
one to 'Python 3.x', also make the date in the banner consistent).
|
||
|
||
___ Edit Doc/tutorial/stdlib.rst and Doc/tutorial/stdlib2.rst, which
|
||
have each one reference to '[Pp]ython3x'.
|
||
|
||
___ Add a new whatsnew/3.x.rst file (with the comment near the top
|
||
and the toplevel sections copied from the previous file) and
|
||
and add it to the toctree in whatsnew/index.rst.
|
||
|
||
___ Update the version number in configure.ac and re-run autoconf.
|
||
|
||
___ Update the version numbers for the Windows builds in PC/ and
|
||
PCbuild/, which have references to python32.
|
||
|
||
$ find PC/ PCbuild/ -type f | xargs sed -i 's/python32/python33/g'
|
||
$ hg mv -f PC/os2emx/python32.def PC/os2emx/python33.def
|
||
$ hg mv -f PC/python32stub.def PC/python33stub.def
|
||
$ hg mv -f PC/python32gen.py PC/python33gen.py
|
||
|
||
___ Commit these changes to the default branch.
|
||
|
||
___ Now, go back to the previously noted revision and make the
|
||
maintenance branch *from there*.
|
||
|
||
$ hg update deadbeef # revision ID noted down before
|
||
$ hg branch 3.2
|
||
|
||
___ When you want to push back your new branch to the main CPython
|
||
repository, the new branch name must be added to the "allow-branches"
|
||
hook configuration, which protects against stray named branches being
|
||
pushed. Login to hg.python.org and edit (as the "hg" user)
|
||
``/data/hg/repos/cpython/.hg/hgrc`` to that effect.
|
||
|
||
___ For a final major release, Doc/tools/sphinxext/static/version_switch.js
|
||
must be updated in all maintained branches, so that the new maintenance
|
||
branch is not "dev" anymore and there is a new "dev" version.
|
||
|
||
___ Push your commits to the remote release clone.
|
||
|
||
$ hg push ssh://hg.python.org/releasing/...
|
||
|
||
___ Notify the experts that they can start building binaries.
|
||
|
||
___ STOP STOP STOP STOP STOP STOP STOP STOP
|
||
|
||
At this point you must receive the "green light" from other experts in
|
||
order to create the release. There are things you can do while you wait
|
||
though, so keep reading until you hit the next STOP.
|
||
|
||
___ The WE builds the Windows helpfile, using (in Doc/)
|
||
|
||
> make.bat htmlhelp (on Windows)
|
||
|
||
to create suitable input for HTML Help Workshop in build/htmlhelp. HTML
|
||
Help Workshop is then fired up on the created python33.hhp file, finally
|
||
resulting in an python33.chm file.
|
||
|
||
___ The WE then generates Windows installer files for each Windows
|
||
target architecture (for Python 3.3, this means x86 and AMD64).
|
||
|
||
- He has one checkout tree per target architecture, and builds the
|
||
pcbuild.sln project for the appropriate architecture.
|
||
|
||
- PC\icons.mak must have been run with nmake.
|
||
|
||
- The cmd.exe window in which this is run must have Cygwin/bin in its
|
||
path (at least for x86).
|
||
|
||
- The cmd.exe window must have MS compiler tools for the target
|
||
architecture in its path (VS 2010 for Python 3.3).
|
||
|
||
- The WE then edits Tools/msi/config.py (a file only present locally)
|
||
to update full_current_version and sets snapshot to false. Currently
|
||
for a release config.py looks like
|
||
|
||
snapshot=0
|
||
full_current_version="3.3.5rc2"
|
||
certname="Python Software Foundation
|
||
PCBUILD='PCbuild\\amd64'
|
||
|
||
The last line is only present for the amd64 checkout.
|
||
|
||
- Now he runs msi.py with ActivePython or Python with pywin32.
|
||
|
||
The WE checksums the files (*.msi, *.chm, *-pdb.zip), uploads them to
|
||
dl-files.psf.io together with gpg signature files, and emails you the
|
||
location and md5sums.
|
||
|
||
___ The ME builds Mac installer packages and uploads them to dl-files.psf.io
|
||
together with gpg signature files.
|
||
|
||
___ Time to build the source tarball. Be sure to update your clone to the
|
||
correct branch. E.g.
|
||
|
||
$ hg update 3.2
|
||
|
||
___ Do a "hg status" in this directory.
|
||
|
||
You should not see any files. I.e. you better not have any uncommitted
|
||
changes in your working directory.
|
||
|
||
___ Make sure you have an up-to-date Sphinx toolchain installed.
|
||
|
||
$ pip install -U Sphinx
|
||
|
||
___ Use the release script to create the source gzip and xz tarballs,
|
||
documentation tar and zip files, and gpg signature files.
|
||
|
||
$ .../release/release.py --export X.Y.ZaN
|
||
|
||
This can take a while for final releases, and it will leave all the
|
||
tarballs and signatures in a subdirectory called 'X.Y.ZaN/src', and the
|
||
built docs in 'X.Y.ZaN/docs' (for final releases).
|
||
|
||
___ scp or rsync all the files to your home directory on dl-files.psf.io.
|
||
|
||
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
|
||
and/or python-committers 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
|
||
steps to take:
|
||
|
||
$ cd /tmp
|
||
$ tar xvf ~/Python-3.2rc2.tgz
|
||
$ cd Python-3.2rc2
|
||
$ ls
|
||
(Do things look reasonable?)
|
||
$ ls Lib
|
||
(Are there stray .pyc files?)
|
||
$ ls Doc/tools
|
||
(Make sure it doesn't contain "docutils", "sphinx", "jinja" or
|
||
"pygments" directories. Also look for stray .pyc files.)
|
||
$ ./configure
|
||
(Loads of configure output)
|
||
$ make test
|
||
(Do all the expected tests pass?)
|
||
|
||
If you're feeling lucky and have some time to kill, or if you are making
|
||
a release candidate or final release, run the full test suite:
|
||
|
||
$ make testall
|
||
|
||
If the tests pass, then you can feel good that the tarball is
|
||
fine. If some of the tests fail, or anything else about the
|
||
freshly unpacked directory looks weird, you better stop now and
|
||
figure out what the problem is.
|
||
|
||
___ Now you need to go to dl-files.psf.io and move all the files in
|
||
place over there. Our policy is that every Python version gets its own
|
||
directory, but each directory contains all releases of that version.
|
||
|
||
___ On dl-files.psf.io, cd /srv/www.python.org/ftp/python/X.Y.Z creating
|
||
it if necessary. Make sure it is owned by group 'downloads' and
|
||
group-writable.
|
||
|
||
___ Move the release .tgz, and .tar.xz files into place, as well as the
|
||
.asc GPG signature files. The Win/Mac binaries are usually put there
|
||
by the experts themselves.
|
||
|
||
Make sure they are world readable. They should also be group
|
||
writable, and group-owned by downloads.
|
||
|
||
___ Use `gpg --verify` to make sure they got uploaded intact.
|
||
|
||
___ If this is a final release: Move the doc zips and tarballs to
|
||
/srv/www.python.org/ftp/python/doc/X.Y.Z, creating the directory
|
||
if necessary, and adapt the "current" symlink in .../doc to point to
|
||
that directory. Note though that if you're releasing a maintenance
|
||
release for an older version, don't change the current link.
|
||
|
||
___ If this is a final release (even a maintenance release), also unpack
|
||
the HTML docs to /srv/docs.python.org/release/X.Y.Z on
|
||
docs-backend.psf.io. Make sure the files are in group "docs". If it
|
||
is a release of a security-fix-only version, tell the DE to build a
|
||
version with the "version switcher" and put it there.
|
||
|
||
___ Let the DE check if the docs are built and work all right.
|
||
|
||
___ If this is a final major release: Tell the DE to adapt redirects for
|
||
docs.python.org/X.Y in the Apache config for docs.python.org, update
|
||
the script Doc/tools/dailybuild.py to point to the right
|
||
stable/development branches, and to install it and make the initial
|
||
checkout. The Doc's version_switcher.js script also needs to be
|
||
updated.
|
||
|
||
___ Note both the documentation and downloads are behind a caching CDN. If
|
||
you change archives after downloading them through the website, you'll
|
||
need to purge the stale data in the CDN like this:
|
||
|
||
$ curl -X PURGE https://www.python.org/ftp/python/2.7.5/Python-2.7.5.tar.xz
|
||
|
||
___ For the extra paranoid, do a completely clean test of the release.
|
||
This includes downloading the tarball from www.python.org.
|
||
|
||
Make sure the md5 checksums match. Then unpack the tarball,
|
||
and do a clean make test.
|
||
|
||
$ make distclean
|
||
$ ./configure
|
||
$ make test
|
||
|
||
To ensure that the regression test suite passes. If not, you
|
||
screwed up somewhere!
|
||
|
||
Now it's time to twiddle the web site.
|
||
|
||
To do these steps, you must have the permission to edit the website. If you
|
||
don't have that, ask someone on pydotorg@python.org for the proper
|
||
permissions. It's insane for you not to have it.
|
||
|
||
XXX This is completely out of date for Django based python.org.
|
||
|
||
This page will probably come in handy:
|
||
|
||
http://docutils.sourceforge.net/docs/user/rst/quickref.html
|
||
|
||
None of the web site updates are automated by release.py.
|
||
|
||
___ Build the basic site.
|
||
|
||
In the top directory, do an `svn update` to get the latest code. In the
|
||
build subdirectory, do `make` to build the site. Do `make serve` to
|
||
start service the pages on localhost:8005. Hit that url to see the site
|
||
as it is right now. At any time you can re-run `make` to update the
|
||
local site. You don't have to restart the server.
|
||
|
||
Don't `svn commit` until you're all done!
|
||
|
||
___ If this is the first release for this version (even a new patch
|
||
version), you'll need to create a subdirectory inside download/releases
|
||
to hold the new version files. It's probably a good idea to copy an
|
||
existing recent directory and twiddle the files in there for the new
|
||
version number.
|
||
|
||
___ Update the version specific pages.
|
||
|
||
___ cd to `download/releases/X.Y.Z`
|
||
___ Edit the version numbers in content.ht
|
||
___ Update the md5 checksums
|
||
|
||
___ Comment out the "This is a preview release" or the "This is a
|
||
production release" paragraph as appropriate
|
||
|
||
Note, you don't have to copy any release files into this directory;
|
||
they only live on dl-files.psf.io in the ftp directory.
|
||
|
||
___ Edit `download/releases/content.ht` to update the version numbers for
|
||
this release. There are a bunch of places you need to touch:
|
||
|
||
___ The subdirectory name as the first element in the Nav rows.
|
||
___ Possibly the Releases section, and possibly in the experimental
|
||
releases section if this is an alpha, beta or release candidate.
|
||
|
||
___ Update the download page, editing `download/content.ht`. Pre-releases are
|
||
added only to the "Testing versions" list.
|
||
|
||
___ If this is a final release...
|
||
|
||
___ Update the 'Quick Links' section on the front page. Edit the
|
||
top-level `content.ht` file.
|
||
|
||
___ For X.Y.Z, edit all the previous X.Y releases' content.ht page to
|
||
point to the new release.
|
||
|
||
___ Update `doc/content.ht` to indicate the new current documentation
|
||
version, and remove the current version from any 'in development'
|
||
section. Update the version in the "What's New" link.
|
||
|
||
___ Add the new version to `doc/versions/content.ht`.
|
||
|
||
___ Add a news section item to the front page by editing newsindex.yml. The
|
||
format should be pretty self evident.
|
||
|
||
___ When everything looks good, `svn commit` in the data directory. This
|
||
will trigger the live site to update itself, and at that point the
|
||
release is live.
|
||
|
||
___ If this is a final release, create a new python.org/X.Y Apache alias
|
||
(or ask pydotorg to do so for you).
|
||
|
||
Now it's time to write the announcement for the mailing lists. This is the
|
||
fuzzy bit because not much can be automated. You can use an earlier
|
||
announcement as a template, but edit it for content!
|
||
|
||
___ STOP STOP STOP STOP STOP STOP STOP STOP
|
||
|
||
___ Have you gotten the green light from the WE?
|
||
|
||
___ Have you gotten the green light from the DE?
|
||
|
||
|
||
___ Once the announcement is ready, send it to the following
|
||
addresses:
|
||
|
||
python-list@python.org
|
||
python-announce@python.org
|
||
python-dev@python.org
|
||
|
||
___ Also post the announcement to <http://blog.python.org>.
|
||
|
||
Now it's time to do some cleaning up. These steps are very important!
|
||
|
||
___ Do the guided post-release steps with the release script.
|
||
|
||
$ .../release/release.py --done X.Y.ZaN
|
||
|
||
Review and commit these changes.
|
||
|
||
___ Merge your release clone into the main development repo:
|
||
|
||
$ cd ../cpython # your clone of the main repo
|
||
$ hg pull ssh://hg.python.org/cpython # update from remote first
|
||
$ hg pull ../cpython-releaseX.Y # now pull from release clone
|
||
|
||
Now merge your release clone's changes in every branch you touched
|
||
(usually only one, except if you made a new maintenance release).
|
||
Easily resolvable conflicts may appear in Misc/NEWS.
|
||
|
||
Commit and push to the main repo.
|
||
|
||
___ You can delete the remote release clone, or simply reuse it for the next
|
||
release.
|
||
|
||
___ Send email to python-committers informing them that the release has been
|
||
published.
|
||
|
||
___ Update any release PEPs (e.g. 361) with the release dates.
|
||
|
||
___ Update the tracker at http://bugs.python.org:
|
||
|
||
___ Flip all the deferred blocker issues back to release blocker
|
||
for the next release.
|
||
|
||
___ Add version X.Y+1 as when version X.Y enters alpha.
|
||
|
||
___ Change non-doc RFEs to version X.Y+1 when version X.Y enters beta.
|
||
|
||
___ Update 'behavior' issues from versions that your release make
|
||
unsupported to the next supported version.
|
||
|
||
___ Review open issues, as this might find lurking showstopper bugs,
|
||
besides reminding people to fix the easy ones they forgot about.
|
||
|
||
|
||
What Next?
|
||
|
||
___ Verify! Pretend you're a user: download the files from python.org, and
|
||
make Python from it. This step is too easy to overlook, and on several
|
||
occasions we've had useless release files. Once a general server problem
|
||
caused mysterious corruption of all files; once the source tarball got
|
||
built incorrectly; more than once the file upload process on SF truncated
|
||
files; and so on.
|
||
|
||
___ Rejoice. Drink. Be Merry. Write a PEP like this one. Or be
|
||
like unto Guido and take A Vacation.
|
||
|
||
You've just made a Python release!
|
||
|
||
|
||
Windows Notes
|
||
|
||
Windows has a MSI installer, various flavors of Windows have
|
||
"special limitations", and the Windows installer also packs
|
||
precompiled "foreign" binaries (Tcl/Tk, expat, etc). So Windows
|
||
testing is tiresome but very necessary.
|
||
|
||
Concurrent with uploading the installer, the WE installs Python
|
||
from it twice: once into the default directory suggested by the
|
||
installer, and later into a directory with embedded spaces in its
|
||
name. For each installation, he runs the full regression suite
|
||
from a DOS box, and both with and without -0. For maintenance
|
||
release, he also tests whether upgrade installations succeed.
|
||
|
||
He also tries *every* shortcut created under Start -> Menu -> the
|
||
Python group. When trying IDLE this way, you need to verify that
|
||
Help -> Python Documentation works. When trying pydoc this way
|
||
(the "Module Docs" Start menu entry), make sure the "Start
|
||
Browser" button works, and make sure you can search for a random
|
||
module (like "random" <wink>) and then that the "go to selected"
|
||
button works.
|
||
|
||
It's amazing how much can go wrong here -- and even more amazing
|
||
how often last-second checkins break one of these things. If
|
||
you're "the Windows geek", keep in mind that you're likely the
|
||
only person routinely testing on Windows, and that Windows is
|
||
simply a mess.
|
||
|
||
Repeat the testing for each target architecture. Try both an
|
||
Admin and a plain User (not Power User) account.
|
||
|
||
|
||
Copyright
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
End:
|