reSTify PEP 102 (#372)

This commit is contained in:
Huang Huang 2017-09-13 07:25:57 +08:00 committed by Guido van Rossum
parent 0f008dd229
commit 3035a38e55
1 changed files with 426 additions and 404 deletions

View File

@ -7,12 +7,14 @@ Author: anthony@interlink.com.au (Anthony Baxter),
guido@python.org (Guido van Rossum)
Status: Superseded
Type: Informational
Content-Type: text/x-rst
Created: 22-Aug-2001 (edited down on 9-Jan-2002 to become PEP 102)
Post-History:
Superseded-By: 101
Replacement Note
================
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
@ -22,6 +24,7 @@ Replacement Note
Abstract
========
Making a Python release is an arduous process that takes a
minimum of half a day's work even for an experienced releaser.
@ -39,6 +42,7 @@ Abstract
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
@ -61,10 +65,10 @@ How to Make A Release
maintenance branch of the major release, e.g. Python 2.1.2 is made
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.
___ 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
(or his duly assigned agents, i.e. Guido the BDFL, Fred Drake for
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
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
to change the PY_VERSION macro, and one or several of the
version subpart macros just above PY_VERSION, as appropriate.
___ 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:
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::
%define version 2.3.1
You also probably want to reset the %define release line
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
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
beta release, but /do/ do this if you're release a new micro,
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
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
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.
___ 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
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
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
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
@ -139,7 +143,7 @@ How to Make A Release
verify with Thomas about changes on Windows, and Jack Jansen
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
@ -147,14 +151,14 @@ How to Make A Release
previous release until now. You can then troll through the
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!
___ 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.
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
in PEP 101.
@ -163,7 +167,7 @@ How to Make A Release
the branch to the trunk during the cleaning up phase.
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
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
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
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
working directory for the branch. E.g.
% 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"
and/or "U" files. I.e. you better not have any uncommitted
changes in your working directory, but you may pick up some of
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
::
% cvs tag r212
Be sure to tag only the python/dist/src subdirectory of the
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
new directory at this location, to be named "Python-X.Y.M". Do
a CVS export of the tagged branch.
::
% cd ~
% cvs -d cvs.sf.net:/cvsroot/python export -rr212 \
-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
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
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 | 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
::
% md5sum Python-2.1.2.tgz
Note that if you don't have the md5sum program, there is a
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.tar.bz2
% 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,
virgin build passes the regression test. Here are the best
steps to take:
steps to take::
% cd /tmp
% 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
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
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.
___ 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
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
% cp -r 2.2.2 2.2.3
@ -282,31 +298,31 @@ How to Make A Release
% cvs add 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
"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 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!)
___ 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
for the new version up to the top and boldify the phrase
"Python X.YaZ is out". Edit for content, and preview locally,
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.
___ 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
Python version gets its own directory, but each directory may
contain several releases. We keep all old releases, moving them
@ -318,41 +334,41 @@ How to Make A Release
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.
___ 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
has g+ws bits on). If this is the first alpha release of a
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
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.
___ 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
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
can use one of Guido's earlier announcements as a template, but
please edit it for content!
Once the announcement is ready, send it to the following
addresses:
addresses::
python-list@python.org
python-announce@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,
select the "Submit" link. Type a suitable subject (e.g. "Python
2.2c1 released" :-) in the Subject box, add some text to the
@ -364,23 +380,25 @@ How to Make A Release
Now it's time to do some cleanup. These steps are very important!
___ Edit the file Include/patchlevel.h so that the PY_VERSION
string says something like "X.YaZ+". Note the trailing `+'
1. Edit the file Include/patchlevel.h so that the PY_VERSION
string says something like "X.YaZ+". Note the trailing '+'
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+"
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.
___ 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
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.
::
% make distclean
% ./configure
% make test
@ -400,6 +418,7 @@ How to Make A Release
What Next?
==========
Rejoice. Drink. Be Merry. Write a PEP like this one. Or be
like unto Guido and take A Vacation.
@ -417,6 +436,7 @@ What Next?
Final Release Notes
===================
The Final release of any major release, e.g. Python 2.2 final, has
special requirements, specifically because it will be one of the
@ -430,25 +450,26 @@ Final Release Notes
we add this extra step to the release process for a final
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>.
The python.org site also needs some tweaking when a new bugfix release
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.
___ 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.
___ /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.
Windows Notes
=============
Windows has a GUI installer, various flavors of Windows have
"special limitations", and the Windows installer also packs
@ -461,7 +482,7 @@ Windows Notes
name. For each installation, he runs the full regression suite
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
Help -> Python Documentation works. When trying pydoc this way
(the "Module Docs" Start menu entry), make sure the "Start
@ -488,11 +509,12 @@ Windows Notes
Copyright
=========
This document has been placed in the public domain.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil