Excise SourceForge file releases from the release process.

This commit is contained in:
Fred Drake 2002-04-11 14:11:27 +00:00
parent 3c595458fe
commit f71e28bfbb
1 changed files with 27 additions and 150 deletions

View File

@ -125,26 +125,12 @@ How to Make A Release
Basically, if it's in Doc/ Fred will take care of it.
___ Tim Peters grabs the HTML and uses this to build the Windows
installer. Tim then creates a new "release" named X.YaZ on the
SourceForge file release manager. (Although, if you get there
first, you should create the new release.)
(Diversion: SF's file manager has "packages" and "releases". We
use packages to name major upcoming releases, e.g. python-2.2 or
python-2.1.1. Inside each package are a number of "releases"
for each new actual release -- i.e. the thing you're building.
An example of a release name is 2.2a3. Once created, packages
and releases are never deleted, but old ones are hidden to
reduce confusion. More on this below.)
If this is the first release for this major Python version, Tim
will create a new package containing the major Python version
number.
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.
executable. He uploads this file to python.org. He then sends
the RM a notice which includes the location and MD5 checksum of
the Windows executable.
Note that Tim's creation of the Windows executable may generate
a few more commits on the branch. Tim will be responsible for
@ -208,39 +194,11 @@ How to Make A Release
freshly unpacked directory looks weird, you better stop now and
figure out what the problem is.
___ Start your upload to SF. You need to get Python-2.1.2.tgz into
SourceForge. This can take a while both because of the time it
takes to upload such a huge file, /and/ because SF has a 30
minute delay built into the file release process. The next few
steps can be taken in parallel, so it's best to start the upload
now and keep an eye on its progress.
I've found that the `ncftpput' program is a great tool to use if
you have it available. You can execute the following command to
do the upload:
% ncftpput upload.sf.net incoming Python-2.1.2.tgz
If you don't have ncftpput around, you can use whatever ftp
client you're comfortable with. Just be sure that you're
uploading this to the "incoming" directory on upload.sf.net.
___ You also need to upload the tgz file to creosote.python.org.
Usually Tim will have already uploaded the exe file to creosote,
but if not, you'll need to do that too. These steps can take a
long time depending on your network bandwidth. You have two
choices:
1) Upload them to SF first, then wget them from creosote. Pros:
easy to do; much friendlier to your own personal bandwidth.
Cons: can take even longer because you're subject to the 30
minute SF file upload delay, and the upload rate from
SF->creosote never seems to get above 20 KB/sec.
2) scp both files from your own machine to creosote. Pros: you
avoid the 30 minute SF delay. Cons: you don't get much else
done if you're on a small pipe.
I usually opt for #2.
___ You need to upload the tgz file to creosote.python.org. Tim
will have already uploaded the exe file to creosote, but if not,
you'll need to do that too. These steps 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
include the announcement.
@ -274,85 +232,14 @@ How to Make A Release
"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.
___ Now we're waiting for the scp to creosote to finish. Da de da,
da de dum, hmm, hmm, dum de dum.
___ Do the SourceForge file release dance.
___ Go to the Python project and click on "Admin"
___ Click on "Edit/Release Files"
___ Since Tim has usually by now created the package and release
we're going to use, scroll down and click on "Edit Releases"
for the package we're releasing into.
___ Find the release named X.YaZ and click on "Edit This Release"
You should now perform Step 1 of the file release dance...
___ The "Status" field should be "Active" not "Hidden"
___ In the text box that says "Paste The Notes In", paste in all
the "What's New" entries from the Misc/NEWS file that describe
this major version of Python, /not/ just the ones for this
particular release. E.g. If we're releasing Python 2.2a3,
we'd include the "What's New" sections for Python 2.2a3,
2.2a2, and 2.2a1.
___ Leave the "Paste The Change Log In" section blank, but click
on "Preserve my pre-formatted text".
___ Hit the Submit/Refresh button for Step 1.
This will bring you back to the file release page. DO NOT do
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
and/or Refresh View" button for Step 2.
And now, Step 3...
___ There should be exactly two files listed here, one is the tgz
file you just added, and the other is the exe file that Tim
added earlier.
___ For the tgz file, be sure that the "Processor" field says
"Any" and the "File Type" field says "Source .gz".
___ Click on "Update/Refresh" for the .tgz file.
___ For the exe file, make sure that the "Processor" field says
"i386" and the "File Type" field says "Other". Tim usually
gets this right <wink>, but if not, make any necessary changes
and click on "Update/Refresh" for the exe file.
Step 4...
DO NOT DO STEP 4 NOW. Wait until after you send out the email
announcement to send the SF email notice.
___ Still on SF, click on the "Files" button at the top of the
page. Find the release you've just made and click on it -- not
on the tgz or exe file, but on the release link under the
package name. E.g. package named python-2.2, click on the
"2.2a3" link.
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
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
scroll down to the "Latest File Releases" section. Find the
package you just made a release for (the Version should be
X.YaZ, and the Date should be today's date). Click on the
"Download" link.
Your new release should be highlighted in pink. Note the url
for this page. Copy and paste it into 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
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.
___ 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
into a "prev" subdirectory when we have a new release.
So, there's a directory called "2.2" which contains
Python-2.2a2.exe and Python-2.2a2.tgz, along with a "prev"
@ -399,9 +286,6 @@ How to Make A Release
python-announce@python.org
python-dev@python.org
___ Go back to the file releases page on SF and complete Step 4,
sending out the email notification.
___ 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
@ -414,12 +298,6 @@ How to Make A Release
Now it's time to do some cleanup. These steps are very important!
___ Go back to SF, Admin->Edit/Release Files. Click on "Edit
Releases" for the package you just added to. For each old
release, click on "Edit This Release" and under Step 1, change
the "Status" to "Hidden". Click on the Step 1 Submit/Refresh
button.
___ 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
@ -431,8 +309,8 @@ How to Make A Release
correct values. Commit this change.
___ For the extra paranoid, do a completely clean test of the
release. This includes downloading the tarball from either
SourceForge or www.python.org.
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.
@ -447,12 +325,12 @@ How to Make A Release
Step 5 ...
Verify! This can be interleaved with Step 4. Pretend you're a
user: download the files from python.org *and* SourceForge, and make
Pythons from them. 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.
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.
What Next?
@ -467,10 +345,9 @@ What Next?
be responsible for making commits to the branch. He's going to
use this to build the MacOS versions. He may send you information
about the Mac release that should be merged into the informational
pages on SourceForge or www.python.org. When he's done, he'll
tag the branch something like "rX.YaZ-mac". He'll also be
responsible for merging any Mac-related changes back into the
trunk.
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
merging any Mac-related changes back into the trunk.
Final Release Notes