Some corrections after proofing this PEP with the 2.2a3 release.
This commit is contained in:
parent
4bbc58e8f3
commit
02b557e348
86
pep-0101.txt
86
pep-0101.txt
|
@ -40,11 +40,11 @@ How to Make A 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.1a3 for
|
||||
Python 2.2 alpha 2, where "a" == alpha, "b" == beta, "rc" ==
|
||||
Python 2.1 alpha 3, where "a" == alpha, "b" == beta, "rc" ==
|
||||
release candidate, and "f" == final. If a micro release number is
|
||||
used, then we'll say X.Y.MaZ.
|
||||
|
||||
- 3 or 4 days before the release, create a branch for X.YaZ.
|
||||
- A day or two before the release, create a branch for X.YaZ.
|
||||
|
||||
All Python development happens on the trunk. A few days before
|
||||
the release, the RM will create a branch for this release. Only
|
||||
|
@ -55,19 +55,38 @@ How to Make A Release
|
|||
|
||||
To create a branch the following steps are taken:
|
||||
|
||||
* Do a CVS update with the -A flag, e.g.
|
||||
% cvs update -A
|
||||
|
||||
* CVS tag the trunk with the symbolic name "rXYaZ-fork", e.g.
|
||||
% cvs tag r2.2a3-fork
|
||||
% cvs tag r22a3-fork
|
||||
|
||||
* Make the branch with the symbolic name "rXYaZ-branch", e.g.
|
||||
% cvs tag -b r2.2a3-branch
|
||||
% cvs tag -b r22a3-branch
|
||||
|
||||
* Check out a clean version of the branch into a new directory.
|
||||
You'll be doing a lot of work in this directory and you want
|
||||
to keep it straight from your trunk working directory. E.g.
|
||||
% cvs -d <cvsroot> -q co -d python-22a3 python/dist/src
|
||||
|
||||
- For the next 3 or 4 days, selectively merge stuff from trunk
|
||||
into branch. For each change you see on the trunk (i.e. via the
|
||||
- Send an email to python-dev@python.org indicating the fork and
|
||||
branch tags you've just created.
|
||||
|
||||
- Put a freeze on check ins into the 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 Tim Peters for Windows). If the RM screwed up
|
||||
and some desperate last minute change to the branch is
|
||||
necessary, it can mean extra work for Fred and Tim. So try to
|
||||
avoid this!
|
||||
|
||||
- In 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.
|
||||
|
||||
- For the next few days, selectively merge stuff from trunk into
|
||||
branch. For each change you see on the trunk (i.e. via the
|
||||
python-checkins mailing list), you need to decide whether the
|
||||
change should also be applied to the branch.
|
||||
|
||||
|
@ -89,13 +108,6 @@ How to Make A Release
|
|||
verify with Tim Peters about changes on Windows, and Jack Jansen
|
||||
about changes on the Mac.
|
||||
|
||||
- Also the night before the release, a freeze is put on check ins
|
||||
into the branch. At this point, nobody except Fred Drake or Tim
|
||||
Peters should make any commits to the branch. If the RM screwed
|
||||
up and some desperate last minute change to the branch is
|
||||
necessary, it can mean extra work for Fred and Tim. So try to
|
||||
avoid this!
|
||||
|
||||
- Once the branch is frozen, Fred Drake needs to create the HTML
|
||||
from the documentation. He does this and uploads the file to
|
||||
www.python.org. Then he tells Tim Peters where this file is.
|
||||
|
@ -117,7 +129,7 @@ How to Make A Release
|
|||
will create a new package containing the major Python version
|
||||
number.
|
||||
|
||||
- Tim does performs his Windows magic, generating an installer
|
||||
- Tim performs his Windows magic, generating an installer
|
||||
executable. He uploads this file to SourceForge under the
|
||||
release he just created. He then sends the RM a notice which
|
||||
includes the MD5 checksum of the Windows executable.
|
||||
|
@ -212,32 +224,31 @@ How to Make A Release
|
|||
- While you're waiting, you can start twiddling the web pages to
|
||||
include the announcement.
|
||||
|
||||
XXX: This section will be rewritten once we CVS-ify the web
|
||||
pages! It's only a rough sketch for now because only the
|
||||
Pythonlabs guys can do this part, and there's no need to expose
|
||||
our cruft. ;)
|
||||
* In the python.org web site CVS tree, cd to the X.Y
|
||||
subdirectory, and copy index.ht to new-index.ht
|
||||
|
||||
% (on leroy) cd ~guido/w/X.Y
|
||||
% cd .../pydotorg/2.2
|
||||
% cp index.ht new-index.ht
|
||||
|
||||
(Edit the file for content: usually you can globally replace
|
||||
* Edit the file 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. You also need to watch out about two
|
||||
specific links in the file, one which references "the full
|
||||
scoop" on changes -- a shownotes link, and one which references
|
||||
the downloads on SF -- a showfiles link. You won't be able to
|
||||
update either link until you've completed the steps below. For
|
||||
now just note what needs to change. Also, update the MD5
|
||||
checksums.)
|
||||
scoop" on changes -- a shownotes link, and one which
|
||||
references the downloads on SF -- a showfiles link. You won't
|
||||
be able to update either link until you've completed the steps
|
||||
below. For now just note what needs to change.
|
||||
|
||||
- Preview the web page by doing a "make" -- NOT a "make install".
|
||||
Also, update the MD5 checksums.
|
||||
|
||||
* Preview the web page by doing a "make" -- NOT a "make install".
|
||||
View the page via a file: url.
|
||||
|
||||
- Similarly, edit the ../index.ht file, i.e. the python.org home
|
||||
* 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 as above. Do NOT
|
||||
do a "make install" yet!
|
||||
for the new version up to the top and boldify the phrase
|
||||
"Python X.YaZ is out". Edit for content, and preview as
|
||||
above. Do NOT do a "make install" yet!
|
||||
|
||||
- Now we're waiting for the ncftpput command, and the scp to
|
||||
creosote to finish. Da de da, da de dum, hmm, hmm, dum de dum.
|
||||
|
@ -265,8 +276,8 @@ How to Make A Release
|
|||
* Hit the Submit/Refresh button for Step 1.
|
||||
|
||||
This will bring you back to the file release page. DO NOT do
|
||||
this step until your ftp upload is complete! Once it is, you
|
||||
can perform Step 2 of the file release dance...
|
||||
the following step until your ftp upload is complete! Once it
|
||||
is, you can perform Step 2 of the file release dance...
|
||||
|
||||
* Click on the checkbox next to the file Python-X.YaZ.tgz. Be
|
||||
sure no other box is checked! Then click on the "Add Files
|
||||
|
@ -299,7 +310,7 @@ How to Make A Release
|
|||
This should be a page that says "Release Name: X.YaZ" and it
|
||||
should contain the "What's New" sections you pasted in earlier.
|
||||
Note the url of this page. Copy and paste it into the
|
||||
~guido/w/X.Y/new-index.ht file you created above. This is the
|
||||
pydotorg/X.Y/new-index.ht file you created above. This is the
|
||||
"shownotes" link mentioned earlier.
|
||||
|
||||
- Now click on the "Summary" link at the top of the page and
|
||||
|
@ -310,7 +321,7 @@ How to Make A Release
|
|||
|
||||
Your new release should be highlighted in pink. Note the url
|
||||
for this page. Copy and paste it into the
|
||||
~guido/w/X.Y/new-index.ht file from above. This is the
|
||||
pydotorg/X.Y/new-index.ht file from above. This is the
|
||||
"showfiles" link mentioned earlier.
|
||||
|
||||
- Now you need to go to creosote.python.org and move all the files
|
||||
|
@ -327,13 +338,18 @@ How to Make A Release
|
|||
|
||||
* On creosote, cd to ~ftp/pub/python/X.Y creating it if
|
||||
necessary.
|
||||
|
||||
* 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
|
||||
sure they are world readable. They should also be group
|
||||
writable.
|
||||
writable, and group-owned by webmaster.
|
||||
|
||||
- Update the X.Y/bugs.ht file if necessary. You may need to get
|
||||
BDFL input for this step.
|
||||
|
||||
- Now preview the new-index.ht file once more. IMPORTANT: follow
|
||||
every link on the page to make sure it goes where you expect it
|
||||
|
|
Loading…
Reference in New Issue