reSTify PEP 102 (#372)
This commit is contained in:
parent
0f008dd229
commit
3035a38e55
340
pep-0102.txt
340
pep-0102.txt
|
@ -7,64 +7,68 @@ Author: anthony@interlink.com.au (Anthony Baxter),
|
||||||
guido@python.org (Guido van Rossum)
|
guido@python.org (Guido van Rossum)
|
||||||
Status: Superseded
|
Status: Superseded
|
||||||
Type: Informational
|
Type: Informational
|
||||||
|
Content-Type: text/x-rst
|
||||||
Created: 22-Aug-2001 (edited down on 9-Jan-2002 to become PEP 102)
|
Created: 22-Aug-2001 (edited down on 9-Jan-2002 to become PEP 102)
|
||||||
Post-History:
|
Post-History:
|
||||||
Superseded-By: 101
|
Superseded-By: 101
|
||||||
|
|
||||||
|
|
||||||
Replacement Note
|
Replacement Note
|
||||||
|
================
|
||||||
|
|
||||||
Although the size of the to-do list in this PEP is much less scary
|
Although the size of the to-do list in this PEP is much less scary
|
||||||
than that in PEP 101, it turns out not to be enough justification
|
than that in PEP 101, it turns out not to be enough justification
|
||||||
for the duplication of information, and with it, the danger of one
|
for the duplication of information, and with it, the danger of one
|
||||||
of the copies to become out of date. Therefore, this PEP is not
|
of the copies to become out of date. Therefore, this PEP is not
|
||||||
maintained anymore, and micro releases are fully covered by PEP 101.
|
maintained anymore, and micro releases are fully covered by PEP 101.
|
||||||
|
|
||||||
|
|
||||||
Abstract
|
Abstract
|
||||||
|
========
|
||||||
|
|
||||||
Making a Python release is an arduous process that takes a
|
Making a Python release is an arduous process that takes a
|
||||||
minimum of half a day's work even for an experienced releaser.
|
minimum of half a day's work even for an experienced releaser.
|
||||||
Until recently, most -- if not all -- of that burden was borne by
|
Until recently, most -- if not all -- of that burden was borne by
|
||||||
Guido himself. But several recent releases have been performed by
|
Guido himself. But several recent releases have been performed by
|
||||||
other folks, so this PEP attempts to collect, in one place, all
|
other folks, so this PEP attempts to collect, in one place, all
|
||||||
the steps needed to make a Python bugfix release.
|
the steps needed to make a Python bugfix release.
|
||||||
|
|
||||||
The major Python release process is covered in PEP 101 - this PEP
|
The major Python release process is covered in PEP 101 - this PEP
|
||||||
is just PEP 101, trimmed down to only include the bits that are
|
is just PEP 101, trimmed down to only include the bits that are
|
||||||
relevant for micro releases, a.k.a. patch, or bug fix releases.
|
relevant for micro releases, a.k.a. patch, or bug fix releases.
|
||||||
|
|
||||||
It is organized as a recipe and you can actually print this out and
|
It is organized as a recipe and you can actually print this out and
|
||||||
check items off as you complete them.
|
check items off as you complete them.
|
||||||
|
|
||||||
|
|
||||||
How to Make A Release
|
How to Make A Release
|
||||||
|
=====================
|
||||||
|
|
||||||
Here are the steps taken to make a Python release. Some steps are
|
Here are the steps taken to make a Python release. Some steps are
|
||||||
more fuzzy than others because there's little that can be
|
more fuzzy than others because there's little that can be
|
||||||
automated (e.g. writing the NEWS entries). Where a step is
|
automated (e.g. writing the NEWS entries). Where a step is
|
||||||
usually performed by An Expert, the name of that expert is given.
|
usually performed by An Expert, the name of that expert is given.
|
||||||
Otherwise, assume the step is done by the Release Manager (RM),
|
Otherwise, assume the step is done by the Release Manager (RM),
|
||||||
the designated person performing the release. Almost every place
|
the designated person performing the release. Almost every place
|
||||||
the RM is mentioned below, this step can also be done by the BDFL
|
the RM is mentioned below, this step can also be done by the BDFL
|
||||||
of course!
|
of course!
|
||||||
|
|
||||||
XXX: We should include a dependency graph to illustrate the steps
|
XXX: We should include a dependency graph to illustrate the steps
|
||||||
that can be taken in parallel, or those that depend on other
|
that can be taken in parallel, or those that depend on other
|
||||||
steps.
|
steps.
|
||||||
|
|
||||||
We use the following conventions in the examples below. Where a
|
We use the following conventions in the examples below. Where a
|
||||||
release number is given, it is of the form X.Y.MaA, e.g. 2.1.2c1
|
release number is given, it is of the form X.Y.MaA, e.g. 2.1.2c1
|
||||||
for Python 2.1.2 release candidate 1, where "a" == alpha, "b" ==
|
for Python 2.1.2 release candidate 1, where "a" == alpha, "b" ==
|
||||||
beta, "c" == release candidate. Final releases are tagged with
|
beta, "c" == release candidate. Final releases are tagged with
|
||||||
"releaseXYZ" in CVS. The micro releases are made from the
|
"releaseXYZ" in CVS. The micro releases are made from the
|
||||||
maintenance branch of the major release, e.g. Python 2.1.2 is made
|
maintenance branch of the major release, e.g. Python 2.1.2 is made
|
||||||
from the release21-maint branch.
|
from the release21-maint branch.
|
||||||
|
|
||||||
___ Send an email to python-dev@python.org indicating the release is
|
1. Send an email to python-dev@python.org indicating the release is
|
||||||
about to start.
|
about to start.
|
||||||
|
|
||||||
___ Put a freeze on check ins into the maintenance branch. At this
|
2. Put a freeze on check ins into the maintenance branch. At this
|
||||||
point, nobody except the RM should make any commits to the branch
|
point, nobody except the RM should make any commits to the branch
|
||||||
(or his duly assigned agents, i.e. Guido the BDFL, Fred Drake for
|
(or his duly assigned agents, i.e. Guido the BDFL, Fred Drake for
|
||||||
documentation, or Thomas Heller for Windows). If the RM screwed up
|
documentation, or Thomas Heller for Windows). If the RM screwed up
|
||||||
|
@ -72,27 +76,27 @@ How to Make A Release
|
||||||
necessary, it can mean extra work for Fred and Thomas. So try to
|
necessary, it can mean extra work for Fred and Thomas. So try to
|
||||||
avoid this!
|
avoid this!
|
||||||
|
|
||||||
___ On the branch, change Include/patchlevel.h in two places, to
|
3. On the branch, change Include/patchlevel.h in two places, to
|
||||||
reflect the new version number you've just created. You'll want
|
reflect the new version number you've just created. You'll want
|
||||||
to change the PY_VERSION macro, and one or several of the
|
to change the PY_VERSION macro, and one or several of the
|
||||||
version subpart macros just above PY_VERSION, as appropriate.
|
version subpart macros just above PY_VERSION, as appropriate.
|
||||||
|
|
||||||
___ Change the "%define version" line of Misc/RPM/python-2.3.spec to the
|
4. Change the "%define version" line of Misc/RPM/python-2.3.spec to the
|
||||||
same string as PY_VERSION was changed to above. E.g:
|
same string as ``PY_VERSION`` was changed to above. E.g::
|
||||||
|
|
||||||
%define version 2.3.1
|
%define version 2.3.1
|
||||||
|
|
||||||
You also probably want to reset the %define release line
|
You also probably want to reset the %define release line
|
||||||
to '1pydotorg' if it's not already that.
|
to '1pydotorg' if it's not already that.
|
||||||
|
|
||||||
___ If you're changing the version number for Python (e.g. from
|
5. If you're changing the version number for Python (e.g. from
|
||||||
Python 2.1.1 to Python 2.1.2), you also need to update the
|
Python 2.1.1 to Python 2.1.2), you also need to update the
|
||||||
README file, which has a big banner at the top proclaiming its
|
README file, which has a big banner at the top proclaiming its
|
||||||
identity. Don't do this if you're just releasing a new alpha or
|
identity. Don't do this if you're just releasing a new alpha or
|
||||||
beta release, but /do/ do this if you're release a new micro,
|
beta release, but /do/ do this if you're release a new micro,
|
||||||
minor or major release.
|
minor or major release.
|
||||||
|
|
||||||
___ The LICENSE file also needs to be changed, due to several
|
6. The LICENSE file also needs to be changed, due to several
|
||||||
references to the release number. As for the README file, changing
|
references to the release number. As for the README file, changing
|
||||||
these are necessary for a new micro, minor or major release.
|
these are necessary for a new micro, minor or major release.
|
||||||
|
|
||||||
|
@ -101,10 +105,10 @@ How to Make A Release
|
||||||
release you are now making. You should update this table in the
|
release you are now making. You should update this table in the
|
||||||
LICENSE file on the CVS trunk too.
|
LICENSE file on the CVS trunk too.
|
||||||
|
|
||||||
___ When the year changes, copyright legends need to be updated in
|
7. When the year changes, copyright legends need to be updated in
|
||||||
many places, including the README and LICENSE files.
|
many places, including the README and LICENSE files.
|
||||||
|
|
||||||
___ For the Windows build, additional files have to be updated.
|
8. For the Windows build, additional files have to be updated.
|
||||||
|
|
||||||
PCbuild/BUILDno.txt contains the Windows build number, see the
|
PCbuild/BUILDno.txt contains the Windows build number, see the
|
||||||
instructions in this file how to change it. Saving the project
|
instructions in this file how to change it. Saving the project
|
||||||
|
@ -120,7 +124,7 @@ How to Make A Release
|
||||||
PC/python_nt.rc, this step is now automated by the build
|
PC/python_nt.rc, this step is now automated by the build
|
||||||
process.)
|
process.)
|
||||||
|
|
||||||
___ After starting the process, the most important thing to do next
|
9. After starting the process, the most important thing to do next
|
||||||
is to update the Misc/NEWS file. Thomas will need this in order to
|
is to update the Misc/NEWS file. Thomas will need this in order to
|
||||||
do the Windows release and he likes to stay up late. This step
|
do the Windows release and he likes to stay up late. This step
|
||||||
can be pretty tedious, so it's best to get to it immediately
|
can be pretty tedious, so it's best to get to it immediately
|
||||||
|
@ -139,7 +143,7 @@ How to Make A Release
|
||||||
verify with Thomas about changes on Windows, and Jack Jansen
|
verify with Thomas about changes on Windows, and Jack Jansen
|
||||||
about changes on the Mac.
|
about changes on the Mac.
|
||||||
|
|
||||||
This command should help you (but substitute the correct -r tag!):
|
This command should help you (but substitute the correct -r tag!)::
|
||||||
|
|
||||||
% cvs log -rr22a1: | python Tools/scripts/logmerge.py > /tmp/news.txt
|
% cvs log -rr22a1: | python Tools/scripts/logmerge.py > /tmp/news.txt
|
||||||
|
|
||||||
|
@ -147,14 +151,14 @@ How to Make A Release
|
||||||
previous release until now. You can then troll through the
|
previous release until now. You can then troll through the
|
||||||
news.txt file looking for interesting things to add to NEWS.
|
news.txt file looking for interesting things to add to NEWS.
|
||||||
|
|
||||||
___ Check your NEWS changes into the maintenance branch. It's easy
|
10. Check your NEWS changes into the maintenance branch. It's easy
|
||||||
to forget to update the release date in this file!
|
to forget to update the release date in this file!
|
||||||
|
|
||||||
___ Check in any changes to IDLE's NEWS.txt. Update the header in
|
11. Check in any changes to IDLE's NEWS.txt. Update the header in
|
||||||
Lib/idlelib/NEWS.txt to reflect its release version and date.
|
Lib/idlelib/NEWS.txt to reflect its release version and date.
|
||||||
Update the IDLE version in Lib/idlelib/idlever.py to match.
|
Update the IDLE version in Lib/idlelib/idlever.py to match.
|
||||||
|
|
||||||
___ Once the release process has started, the documentation needs to
|
11. Once the release process has started, the documentation needs to
|
||||||
be built and posted on python.org according to the instructions
|
be built and posted on python.org according to the instructions
|
||||||
in PEP 101.
|
in PEP 101.
|
||||||
|
|
||||||
|
@ -163,7 +167,7 @@ How to Make A Release
|
||||||
the branch to the trunk during the cleaning up phase.
|
the branch to the trunk during the cleaning up phase.
|
||||||
Basically, if it's in Doc/ Fred will take care of it.
|
Basically, if it's in Doc/ Fred will take care of it.
|
||||||
|
|
||||||
___ Thomas compiles everything with MSVC 6.0 SP5, and moves the
|
12. Thomas compiles everything with MSVC 6.0 SP5, and moves the
|
||||||
python23.chm file into the src/chm directory. The installer
|
python23.chm file into the src/chm directory. The installer
|
||||||
executable is then generated with Wise Installation System.
|
executable is then generated with Wise Installation System.
|
||||||
|
|
||||||
|
@ -189,65 +193,77 @@ How to Make A Release
|
||||||
merging Windows-specific changes from trunk to branch, and from
|
merging Windows-specific changes from trunk to branch, and from
|
||||||
branch to trunk.
|
branch to trunk.
|
||||||
|
|
||||||
___ Sean performs his Red Hat magic, generating a set of RPMs. He
|
13. Sean performs his Red Hat magic, generating a set of RPMs. He
|
||||||
uploads these files to python.org. He then sends the RM a notice
|
uploads these files to python.org. He then sends the RM a notice
|
||||||
which includes the location and MD5 checksum of the RPMs.
|
which includes the location and MD5 checksum of the RPMs.
|
||||||
|
|
||||||
___ It's Build Time!
|
14. It's Build Time!
|
||||||
|
|
||||||
Now, you're ready to build the source tarball. First cd to your
|
Now, you're ready to build the source tarball. First cd to your
|
||||||
working directory for the branch. E.g.
|
working directory for the branch. E.g.
|
||||||
% cd .../python-22a3
|
% cd .../python-22a3
|
||||||
|
|
||||||
___ Do a "cvs update" in this directory. Do NOT include the -A flag!
|
15. Do a "cvs update" in this directory. Do NOT include the -A flag!
|
||||||
|
|
||||||
You should not see any "M" files, but you may see several "P"
|
You should not see any "M" files, but you may see several "P"
|
||||||
and/or "U" files. I.e. you better not have any uncommitted
|
and/or "U" files. I.e. you better not have any uncommitted
|
||||||
changes in your working directory, but you may pick up some of
|
changes in your working directory, but you may pick up some of
|
||||||
Fred's or Thomas's last minute changes.
|
Fred's or Thomas's last minute changes.
|
||||||
|
|
||||||
___ Now tag the branch using a symbolic name like "rXYMaZ",
|
16. Now tag the branch using a symbolic name like "rXYMaZ",
|
||||||
e.g. r212
|
e.g. r212
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
% cvs tag r212
|
% cvs tag r212
|
||||||
|
|
||||||
Be sure to tag only the python/dist/src subdirectory of the
|
Be sure to tag only the python/dist/src subdirectory of the
|
||||||
Python CVS tree!
|
Python CVS tree!
|
||||||
|
|
||||||
___ Change to a neutral directory, i.e. one in which you can do a
|
17. Change to a neutral directory, i.e. one in which you can do a
|
||||||
fresh, virgin, cvs export of the branch. You will be creating a
|
fresh, virgin, cvs export of the branch. You will be creating a
|
||||||
new directory at this location, to be named "Python-X.Y.M". Do
|
new directory at this location, to be named "Python-X.Y.M". Do
|
||||||
a CVS export of the tagged branch.
|
a CVS export of the tagged branch.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
% cd ~
|
% cd ~
|
||||||
% cvs -d cvs.sf.net:/cvsroot/python export -rr212 \
|
% cvs -d cvs.sf.net:/cvsroot/python export -rr212 \
|
||||||
-d Python-2.1.2 python/dist/src
|
-d Python-2.1.2 python/dist/src
|
||||||
|
|
||||||
___ Generate the tarball. Note that we're not using the `z' option
|
18. Generate the tarball. Note that we're not using the 'z' option
|
||||||
on the tar command because 1) that's only supported by GNU tar
|
on the tar command because 1) that's only supported by GNU tar
|
||||||
as far as we know, and 2) we're going to max out the compression
|
as far as we know, and 2) we're going to max out the compression
|
||||||
level, which isn't a supported option. We generate both tar.gz
|
level, which isn't a supported option. We generate both tar.gz
|
||||||
tar.bz2 formats, as the latter is about 1/6th smaller.
|
tar.bz2 formats, as the latter is about 1/6th smaller.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
% tar -cf - Python-2.1.2 | gzip -9 > Python-2.1.2.tgz
|
% tar -cf - Python-2.1.2 | gzip -9 > Python-2.1.2.tgz
|
||||||
% tar -cf - Python-2.1.2 | bzip2 -9 > Python-2.1.2.tar.bz2
|
% tar -cf - Python-2.1.2 | bzip2 -9 > Python-2.1.2.tar.bz2
|
||||||
|
|
||||||
___ Calculate the MD5 checksum of the tgz and tar.bz2 files you
|
19. Calculate the MD5 checksum of the tgz and tar.bz2 files you
|
||||||
just created
|
just created
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
% md5sum Python-2.1.2.tgz
|
% md5sum Python-2.1.2.tgz
|
||||||
|
|
||||||
Note that if you don't have the md5sum program, there is a
|
Note that if you don't have the md5sum program, there is a
|
||||||
Python replacement in the Tools/scripts/md5sum.py file.
|
Python replacement in the Tools/scripts/md5sum.py file.
|
||||||
|
|
||||||
___ Create GPG keys for each of the files.
|
20. Create GPG keys for each of the files.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
% gpg -ba Python-2.1.2.tgz
|
% gpg -ba Python-2.1.2.tgz
|
||||||
% gpg -ba Python-2.1.2.tar.bz2
|
% gpg -ba Python-2.1.2.tar.bz2
|
||||||
% gpg -ba Python-2.1.2.exe
|
% gpg -ba Python-2.1.2.exe
|
||||||
|
|
||||||
___ Now you want to perform the very important step of checking the
|
21. Now you want to perform the very important step of checking the
|
||||||
tarball you just created, to make sure a completely clean,
|
tarball you just created, to make sure a completely clean,
|
||||||
virgin build passes the regression test. Here are the best
|
virgin build passes the regression test. Here are the best
|
||||||
steps to take:
|
steps to take::
|
||||||
|
|
||||||
% cd /tmp
|
% cd /tmp
|
||||||
% tar zxvf ~/Python-2.1.2.tgz
|
% tar zxvf ~/Python-2.1.2.tgz
|
||||||
|
@ -264,17 +280,17 @@ How to Make A Release
|
||||||
freshly unpacked directory looks weird, you better stop now and
|
freshly unpacked directory looks weird, you better stop now and
|
||||||
figure out what the problem is.
|
figure out what the problem is.
|
||||||
|
|
||||||
___ You need to upload the tgz and the exe file to creosote.python.org.
|
22. You need to upload the tgz and the exe file to creosote.python.org.
|
||||||
This step can take a long time depending on your network
|
This step can take a long time depending on your network
|
||||||
bandwidth. scp both files from your own machine to creosote.
|
bandwidth. scp both files from your own machine to creosote.
|
||||||
|
|
||||||
___ While you're waiting, you can start twiddling the web pages to
|
23. While you're waiting, you can start twiddling the web pages to
|
||||||
include the announcement.
|
include the announcement.
|
||||||
|
|
||||||
___ In the top of the python.org web site CVS tree, create a
|
1. In the top of the python.org web site CVS tree, create a
|
||||||
subdirectory for the X.Y.Z release. You can actually copy an
|
subdirectory for the X.Y.Z release. You can actually copy an
|
||||||
earlier patch release's subdirectory, but be sure to delete
|
earlier patch release's subdirectory, but be sure to delete
|
||||||
the X.Y.Z/CVS directory and "cvs add X.Y.Z", for example:
|
the X.Y.Z/CVS directory and "cvs add X.Y.Z", for example::
|
||||||
|
|
||||||
% cd .../pydotorg
|
% cd .../pydotorg
|
||||||
% cp -r 2.2.2 2.2.3
|
% cp -r 2.2.2 2.2.3
|
||||||
|
@ -282,31 +298,31 @@ How to Make A Release
|
||||||
% cvs add 2.2.3
|
% cvs add 2.2.3
|
||||||
% cd 2.2.3
|
% cd 2.2.3
|
||||||
|
|
||||||
___ Edit the files for content: usually you can globally replace
|
2. Edit the files for content: usually you can globally replace
|
||||||
X.Ya(Z-1) with X.YaZ. However, you'll need to think about the
|
X.Ya(Z-1) with X.YaZ. However, you'll need to think about the
|
||||||
"What's New?" section.
|
"What's New?" section.
|
||||||
|
|
||||||
___ Copy the Misc/NEWS file to NEWS.txt in the X.Y.Z directory for
|
3. Copy the Misc/NEWS file to NEWS.txt in the X.Y.Z directory for
|
||||||
python.org; this contains the "full scoop" of changes to
|
python.org; this contains the "full scoop" of changes to
|
||||||
Python since the previous release for this version of Python.
|
Python since the previous release for this version of Python.
|
||||||
|
|
||||||
___ Copy the .asc GPG signatures you created earlier here as well.
|
4. Copy the .asc GPG signatures you created earlier here as well.
|
||||||
|
|
||||||
___ Also, update the MD5 checksums.
|
5. Also, update the MD5 checksums.
|
||||||
|
|
||||||
___ Preview the web page by doing a "make" or "make install" (as
|
6. Preview the web page by doing a "make" or "make install" (as
|
||||||
long as you've created a new directory for this release!)
|
long as you've created a new directory for this release!)
|
||||||
|
|
||||||
___ Similarly, edit the ../index.ht file, i.e. the python.org home
|
7. Similarly, edit the ../index.ht file, i.e. the python.org home
|
||||||
page. In the Big Blue Announcement Block, move the paragraph
|
page. In the Big Blue Announcement Block, move the paragraph
|
||||||
for the new version up to the top and boldify the phrase
|
for the new version up to the top and boldify the phrase
|
||||||
"Python X.YaZ is out". Edit for content, and preview locally,
|
"Python X.YaZ is out". Edit for content, and preview locally,
|
||||||
but do NOT do a "make install" yet!
|
but do NOT do a "make install" yet!
|
||||||
|
|
||||||
___ Now we're waiting for the scp to creosote to finish. Da de da,
|
24. Now we're waiting for the scp to creosote to finish. Da de da,
|
||||||
da de dum, hmm, hmm, dum de dum.
|
da de dum, hmm, hmm, dum de dum.
|
||||||
|
|
||||||
___ Once that's done you need to go to creosote.python.org and move
|
25. Once that's done you need to go to creosote.python.org and move
|
||||||
all the files in place over there. Our policy is that every
|
all the files in place over there. Our policy is that every
|
||||||
Python version gets its own directory, but each directory may
|
Python version gets its own directory, but each directory may
|
||||||
contain several releases. We keep all old releases, moving them
|
contain several releases. We keep all old releases, moving them
|
||||||
|
@ -318,41 +334,41 @@ How to Make A Release
|
||||||
|
|
||||||
So...
|
So...
|
||||||
|
|
||||||
___ On creosote, cd to ~ftp/pub/python/X.Y creating it if
|
1. On creosote, cd to ~ftp/pub/python/X.Y creating it if
|
||||||
necessary.
|
necessary.
|
||||||
|
|
||||||
___ Move the previous release files to a directory called "prev"
|
2. Move the previous release files to a directory called "prev"
|
||||||
creating the directory if necessary (make sure the directory
|
creating the directory if necessary (make sure the directory
|
||||||
has g+ws bits on). If this is the first alpha release of a
|
has g+ws bits on). If this is the first alpha release of a
|
||||||
new Python version, skip this step.
|
new Python version, skip this step.
|
||||||
|
|
||||||
___ Move the .tgz file and the .exe file to this directory. Make
|
3. Move the .tgz file and the .exe file to this directory. Make
|
||||||
sure they are world readable. They should also be group
|
sure they are world readable. They should also be group
|
||||||
writable, and group-owned by webmaster.
|
writable, and group-owned by webmaster.
|
||||||
|
|
||||||
___ md5sum the files and make sure they got uploaded intact.
|
4. md5sum the files and make sure they got uploaded intact.
|
||||||
|
|
||||||
|
|
||||||
___ Update the X.Y/bugs.ht file if necessary. It is best to get
|
26. the X.Y/bugs.ht file if necessary. It is best to get
|
||||||
BDFL input for this step.
|
BDFL input for this step.
|
||||||
|
|
||||||
___ Go up to the parent directory (i.e. the root of the web page
|
27. Go up to the parent directory (i.e. the root of the web page
|
||||||
hierarchy) and do a "make install" there. You're release is now
|
hierarchy) and do a "make install" there. You're release is now
|
||||||
live!
|
live!
|
||||||
|
|
||||||
___ Now it's time to write the announcement for the mailing lists.
|
28. Now it's time to write the announcement for the mailing lists.
|
||||||
This is the fuzzy bit because not much can be automated. You
|
This is the fuzzy bit because not much can be automated. You
|
||||||
can use one of Guido's earlier announcements as a template, but
|
can use one of Guido's earlier announcements as a template, but
|
||||||
please edit it for content!
|
please edit it for content!
|
||||||
|
|
||||||
Once the announcement is ready, send it to the following
|
Once the announcement is ready, send it to the following
|
||||||
addresses:
|
addresses::
|
||||||
|
|
||||||
python-list@python.org
|
python-list@python.org
|
||||||
python-announce@python.org
|
python-announce@python.org
|
||||||
python-dev@python.org
|
python-dev@python.org
|
||||||
|
|
||||||
___ Send a SourceForge News Item about the release. From the
|
29. Send a SourceForge News Item about the release. From the
|
||||||
project's "menu bar", select the "News" link; once in News,
|
project's "menu bar", select the "News" link; once in News,
|
||||||
select the "Submit" link. Type a suitable subject (e.g. "Python
|
select the "Submit" link. Type a suitable subject (e.g. "Python
|
||||||
2.2c1 released" :-) in the Subject box, add some text to the
|
2.2c1 released" :-) in the Subject box, add some text to the
|
||||||
|
@ -362,25 +378,27 @@ How to Make A Release
|
||||||
|
|
||||||
Feel free to remove any old news items.
|
Feel free to remove any old news items.
|
||||||
|
|
||||||
Now it's time to do some cleanup. These steps are very important!
|
Now it's time to do some cleanup. These steps are very important!
|
||||||
|
|
||||||
___ Edit the file Include/patchlevel.h so that the PY_VERSION
|
1. Edit the file Include/patchlevel.h so that the PY_VERSION
|
||||||
string says something like "X.YaZ+". Note the trailing `+'
|
string says something like "X.YaZ+". Note the trailing '+'
|
||||||
indicating that the trunk is going to be moving forward with
|
indicating that the trunk is going to be moving forward with
|
||||||
development. E.g. the line should look like:
|
development. E.g. the line should look like::
|
||||||
|
|
||||||
#define PY_VERSION "2.1.2+"
|
#define PY_VERSION "2.1.2+"
|
||||||
|
|
||||||
Make sure that the other PY_ version macros contain the
|
Make sure that the other ``PY_`` version macros contain the
|
||||||
correct values. Commit this change.
|
correct values. Commit this change.
|
||||||
|
|
||||||
___ For the extra paranoid, do a completely clean test of the
|
2. For the extra paranoid, do a completely clean test of the
|
||||||
release. This includes downloading the tarball from
|
release. This includes downloading the tarball from
|
||||||
www.python.org.
|
www.python.org.
|
||||||
|
|
||||||
___ Make sure the md5 checksums match. Then unpack the tarball,
|
3. Make sure the md5 checksums match. Then unpack the tarball,
|
||||||
and do a clean make test.
|
and do a clean make test.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
% make distclean
|
% make distclean
|
||||||
% ./configure
|
% ./configure
|
||||||
% make test
|
% make test
|
||||||
|
@ -388,112 +406,116 @@ How to Make A Release
|
||||||
To ensure that the regression test suite passes. If not, you
|
To ensure that the regression test suite passes. If not, you
|
||||||
screwed up somewhere!
|
screwed up somewhere!
|
||||||
|
|
||||||
Step 5 ...
|
Step 5 ...
|
||||||
|
|
||||||
Verify! This can be interleaved with Step 4. Pretend you're a
|
Verify! This can be interleaved with Step 4. Pretend you're a
|
||||||
user: download the files from python.org, and make Python from
|
user: download the files from python.org, and make Python from
|
||||||
it. This step is too easy to overlook, and on several occasions
|
it. This step is too easy to overlook, and on several occasions
|
||||||
we've had useless release files. Once a general server problem
|
we've had useless release files. Once a general server problem
|
||||||
caused mysterious corruption of all files; once the source tarball
|
caused mysterious corruption of all files; once the source tarball
|
||||||
got built incorrectly; more than once the file upload process on
|
got built incorrectly; more than once the file upload process on
|
||||||
SF truncated files; and so on.
|
SF truncated files; and so on.
|
||||||
|
|
||||||
|
|
||||||
What Next?
|
What Next?
|
||||||
|
==========
|
||||||
|
|
||||||
Rejoice. Drink. Be Merry. Write a PEP like this one. Or be
|
Rejoice. Drink. Be Merry. Write a PEP like this one. Or be
|
||||||
like unto Guido and take A Vacation.
|
like unto Guido and take A Vacation.
|
||||||
|
|
||||||
You've just made a Python release!
|
You've just made a Python release!
|
||||||
|
|
||||||
Actually, there is one more step. You should turn over ownership
|
Actually, there is one more step. You should turn over ownership
|
||||||
of the branch to Jack Jansen. All this means is that now he will
|
of the branch to Jack Jansen. All this means is that now he will
|
||||||
be responsible for making commits to the branch. He's going to
|
be responsible for making commits to the branch. He's going to
|
||||||
use this to build the MacOS versions. He may send you information
|
use this to build the MacOS versions. He may send you information
|
||||||
about the Mac release that should be merged into the informational
|
about the Mac release that should be merged into the informational
|
||||||
pages on www.python.org. When he's done, he'll tag the branch
|
pages on www.python.org. When he's done, he'll tag the branch
|
||||||
something like "rX.YaZ-mac". He'll also be responsible for
|
something like "rX.YaZ-mac". He'll also be responsible for
|
||||||
merging any Mac-related changes back into the trunk.
|
merging any Mac-related changes back into the trunk.
|
||||||
|
|
||||||
|
|
||||||
Final Release Notes
|
Final Release Notes
|
||||||
|
===================
|
||||||
|
|
||||||
The Final release of any major release, e.g. Python 2.2 final, has
|
The Final release of any major release, e.g. Python 2.2 final, has
|
||||||
special requirements, specifically because it will be one of the
|
special requirements, specifically because it will be one of the
|
||||||
longest lived releases (i.e. betas don't last more than a couple
|
longest lived releases (i.e. betas don't last more than a couple
|
||||||
of weeks, but final releases can last for years!).
|
of weeks, but final releases can last for years!).
|
||||||
|
|
||||||
For this reason we want to have a higher coordination between the
|
For this reason we want to have a higher coordination between the
|
||||||
three major releases: Windows, Mac, and source. The Windows and
|
three major releases: Windows, Mac, and source. The Windows and
|
||||||
source releases benefit from the close proximity of the respective
|
source releases benefit from the close proximity of the respective
|
||||||
release-bots. But the Mac-bot, Jack Jansen, is 6 hours away. So
|
release-bots. But the Mac-bot, Jack Jansen, is 6 hours away. So
|
||||||
we add this extra step to the release process for a final
|
we add this extra step to the release process for a final
|
||||||
release:
|
release:
|
||||||
|
|
||||||
___ Hold up the final release until Jack approves, or until we
|
1. Hold up the final release until Jack approves, or until we
|
||||||
lose patience <wink>.
|
lose patience <wink>.
|
||||||
|
|
||||||
The python.org site also needs some tweaking when a new bugfix release
|
The python.org site also needs some tweaking when a new bugfix release
|
||||||
is issued.
|
is issued.
|
||||||
|
|
||||||
___ The documentation should be installed at doc/<version>/.
|
2. The documentation should be installed at doc/<version>/.
|
||||||
|
|
||||||
___ Add a link from doc/<previous-minor-release>/index.ht to the
|
3. Add a link from doc/<previous-minor-release>/index.ht to the
|
||||||
documentation for the new version.
|
documentation for the new version.
|
||||||
|
|
||||||
___ All older doc/<old-release>/index.ht files should be updated to
|
4. All older doc/<old-release>/index.ht files should be updated to
|
||||||
point to the documentation for the new version.
|
point to the documentation for the new version.
|
||||||
|
|
||||||
___ /robots.txt should be modified to prevent the old version's
|
5. /robots.txt should be modified to prevent the old version's
|
||||||
documentation from being crawled by search engines.
|
documentation from being crawled by search engines.
|
||||||
|
|
||||||
|
|
||||||
Windows Notes
|
Windows Notes
|
||||||
|
=============
|
||||||
|
|
||||||
Windows has a GUI installer, various flavors of Windows have
|
Windows has a GUI installer, various flavors of Windows have
|
||||||
"special limitations", and the Windows installer also packs
|
"special limitations", and the Windows installer also packs
|
||||||
precompiled "foreign" binaries (Tcl/Tk, expat, etc). So Windows
|
precompiled "foreign" binaries (Tcl/Tk, expat, etc). So Windows
|
||||||
testing is tiresome but very necessary.
|
testing is tiresome but very necessary.
|
||||||
|
|
||||||
Concurrent with uploading the installer, Thomas installs Python
|
Concurrent with uploading the installer, Thomas installs Python
|
||||||
from it twice: once into the default directory suggested by the
|
from it twice: once into the default directory suggested by the
|
||||||
installer, and later into a directory with embedded spaces in its
|
installer, and later into a directory with embedded spaces in its
|
||||||
name. For each installation, he runs the full regression suite
|
name. For each installation, he runs the full regression suite
|
||||||
from a DOS box, and both with and without -0.
|
from a DOS box, and both with and without -0.
|
||||||
|
|
||||||
He also tries *every* shortcut created under Start -> Menu -> the
|
He also tries **every** shortcut created under Start -> Menu -> the
|
||||||
Python group. When trying IDLE this way, you need to verify that
|
Python group. When trying IDLE this way, you need to verify that
|
||||||
Help -> Python Documentation works. When trying pydoc this way
|
Help -> Python Documentation works. When trying pydoc this way
|
||||||
(the "Module Docs" Start menu entry), make sure the "Start
|
(the "Module Docs" Start menu entry), make sure the "Start
|
||||||
Browser" button works, and make sure you can search for a random
|
Browser" button works, and make sure you can search for a random
|
||||||
module (Thomas uses "random" <wink>) and then that the "go to
|
module (Thomas uses "random" <wink>) and then that the "go to
|
||||||
selected" button works.
|
selected" button works.
|
||||||
|
|
||||||
It's amazing how much can go wrong here -- and even more amazing
|
It's amazing how much can go wrong here -- and even more amazing
|
||||||
how often last-second checkins break one of these things. If
|
how often last-second checkins break one of these things. If
|
||||||
you're "the Windows geek", keep in mind that you're likely the
|
you're "the Windows geek", keep in mind that you're likely the
|
||||||
only person routinely testing on Windows, and that Windows is
|
only person routinely testing on Windows, and that Windows is
|
||||||
simply a mess.
|
simply a mess.
|
||||||
|
|
||||||
Repeat all of the above on at least one flavor of Win9x, and one
|
Repeat all of the above on at least one flavor of Win9x, and one
|
||||||
of NT/2000/XP. On NT/2000/XP, try both an Admin and a plain User
|
of NT/2000/XP. On NT/2000/XP, try both an Admin and a plain User
|
||||||
(not Power User) account.
|
(not Power User) account.
|
||||||
|
|
||||||
WRT Step 5 above (verify the release media), since by the time
|
WRT Step 5 above (verify the release media), since by the time
|
||||||
release files are ready to download Thomas has generally run many
|
release files are ready to download Thomas has generally run many
|
||||||
Windows tests on the installer he uploaded, he usually doesn't do
|
Windows tests on the installer he uploaded, he usually doesn't do
|
||||||
anything for Step 5 except a full byte-comparison ("fc /b" if
|
anything for Step 5 except a full byte-comparison ("fc /b" if
|
||||||
using a Windows shell) of the downloaded file against the file he
|
using a Windows shell) of the downloaded file against the file he
|
||||||
uploaded.
|
uploaded.
|
||||||
|
|
||||||
|
|
||||||
Copyright
|
Copyright
|
||||||
|
=========
|
||||||
|
|
||||||
This document has been placed in the public domain.
|
This document has been placed in the public domain.
|
||||||
|
|
||||||
|
|
||||||
|
..
|
||||||
Local Variables:
|
Local Variables:
|
||||||
mode: indented-text
|
mode: indented-text
|
||||||
indent-tabs-mode: nil
|
indent-tabs-mode: nil
|
||||||
End:
|
End:
|
||||||
|
|
Loading…
Reference in New Issue