Excise SourceForge file releases from the release process.
This commit is contained in:
parent
3c595458fe
commit
f71e28bfbb
177
pep-0102.txt
177
pep-0102.txt
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue