Update PEP 101 a bit. Remove outdated Windows instructions.
This commit is contained in:
Georg Brandl
parent
beefe7940a
commit
e95861fb26
95
pep-0101.txt
95
pep-0101.txt
|
|
@ -59,7 +59,7 @@ How to Make A Release
|
|||
done by the Release Manager (RM), the designated person performing the
|
||||
release. The roles and their current experts are:
|
||||
|
||||
* RM = Release Manager: Georg Brandl <georg@python.org> (Central Europe)
|
||||
* RM = Release Manager: Larry Hastings <larry@hastings.org> (US)
|
||||
* WE = Windows: Martin von Loewis <martin@v.loewis.de> (Central Europe)
|
||||
* ME = Mac: Ned Deily <nad@acm.org> (US)
|
||||
* DE = Docs: Georg Brandl <georg@python.org> (Central Europe)
|
||||
|
|
@ -70,13 +70,10 @@ How to Make A Release
|
|||
in different timezones, the RM must ensure that the release tag is
|
||||
created in enough time for the Experts to cut binary releases.
|
||||
|
||||
IT IS HIGHLY RECOMMENDED THAT YOU AT LEAST TAG THE TREE 24 HOURS
|
||||
BEFORE A FINAL RELEASE. This will give the Experts enough time to
|
||||
do their bits before the announcement goes out.
|
||||
|
||||
In any case, the RM MUST wait for the "green light" from the
|
||||
following experts before updating the web pages and sending the
|
||||
announcement: WE, DE
|
||||
You should not make the release public (by updating the website and
|
||||
sending announcements) before all experts have updated their bits.
|
||||
In rare cases where the expert for Windows or Mac is MIA, you may add
|
||||
a message "(Platform) binaries will be provided shortly" and proceed.
|
||||
|
||||
XXX: We should include a dependency graph to illustrate the steps that can
|
||||
be taken in parallel, or those that depend on other steps.
|
||||
|
|
@ -139,14 +136,14 @@ How to Make A Release
|
|||
|
||||
Create a local clone of the cpython repository (called the "release
|
||||
clone" from now on).
|
||||
|
||||
|
||||
Also clone the repo at http://hg.python.org/cpython using the
|
||||
server-side clone feature. The name of the new clone should preferably
|
||||
have a "releasing/" prefix. The other experts will use the release
|
||||
clone for making the binaries, so it is important that they have access
|
||||
to it!
|
||||
|
||||
Optionally, set up your local release clone to push to the remote
|
||||
It's best to set up your local release clone to push to the remote
|
||||
release clone by default (by editing .hg/hgrc to that effect).
|
||||
|
||||
___ Notify all committers by sending email to python-committers@python.org.
|
||||
|
|
@ -208,10 +205,6 @@ How to Make A Release
|
|||
___ PC/python_nt.rc sets up the DLL version resource for Windows
|
||||
(displayed when you right-click on the DLL and select
|
||||
Properties).
|
||||
___ The license.ht file for the distribution on the website
|
||||
contains what purports to be an HTML-ized copy of the LICENSE
|
||||
file from the distribution. You'll need to bump the version number to
|
||||
the one you're releasing. BROKEN
|
||||
|
||||
___ Check with the IE (if there is one <wink>) to be sure that
|
||||
Lib/idlelib/NEWS.txt has been similarly updated.
|
||||
|
|
@ -266,7 +259,7 @@ How to Make A Release
|
|||
$ hg mv -f PC/python32gen.py PC/python33gen.py
|
||||
|
||||
___ Commit these changes to the default branch.
|
||||
|
||||
|
||||
___ Now, go back to the previously noted revision and make the
|
||||
maintenance branch *from there*.
|
||||
|
||||
|
|
@ -285,43 +278,23 @@ How to Make A Release
|
|||
order to create the release. There are things you can do while you wait
|
||||
though, so keep reading until you hit the next STOP.
|
||||
|
||||
___ XXX The WE builds the Windows helpfile, using (in Doc/) either
|
||||
___ The WE builds the Windows helpfile, using (in Doc/)
|
||||
|
||||
$ make htmlhelp (on Unix)
|
||||
|
||||
or
|
||||
|
||||
> make.bat htmlhelp (on Windows)
|
||||
> make.bat htmlhelp (on Windows)
|
||||
|
||||
to create suitable input for HTML Help Workshop in build/htmlhelp. HTML
|
||||
Help Workshop is then fired up on the created python26.hhp file, finally
|
||||
resulting in an python26.chm file. He then copies the file into the Doc
|
||||
directories of the build trees (once for each target architecture).
|
||||
Help Workshop is then fired up on the created python33.hhp file, finally
|
||||
resulting in an python33.chm file.
|
||||
|
||||
XXX The CHM file should also be scp'd to the docs download location.
|
||||
___ The WE then generates Windows installer files for each Windows
|
||||
target architecture (for Python 3.3, this means x86 and AMD64).
|
||||
|
||||
___ XXX The WE then generates Windows installer files for each Windows
|
||||
target architecture (for Python 2.6, this means x86 and AMD64). He has
|
||||
one checkout tree per target architecture, and builds the pcbuild.sln
|
||||
project for the appropriate architecture. He then edits
|
||||
Tools/msi/config.py to update full_current_version, sets snapshot to
|
||||
False and runs msi.py with ActivePython 2.5 or Python 2.5 with pywin32.
|
||||
For that to work, the following prerequisites must be met:
|
||||
The WE checksums the files (*.msi, *.chm, *-pdb.zip), uploads them to
|
||||
dinsdale together with gpg signature files, and emails you the location
|
||||
and md5sums.
|
||||
|
||||
- PC\icons.mak must have been run with nmake.
|
||||
|
||||
- The cmd.exe window in which this is run must have Cygwin/bin in its
|
||||
path (atleast for x86).
|
||||
|
||||
- The cmd.exe window must have MS compiler tools for the target
|
||||
architecture in its path (VS 2003 for x86, the platform SDK for
|
||||
AMD64).
|
||||
|
||||
- The cmd.exe window must also have cabarc.exe from the CAB SDK in its
|
||||
path.
|
||||
|
||||
The WE checksums the files (*.msi and *.chm), uploads them to some place
|
||||
in the net, and emails you the location and md5sums.
|
||||
___ The ME builds Mac installer packages and uploads them to dinsdale together
|
||||
with gpg signature files.
|
||||
|
||||
___ Time to build the source tarball. Be sure to update your clone to the
|
||||
correct branch. E.g.
|
||||
|
|
@ -333,13 +306,18 @@ How to Make A Release
|
|||
You should not see any files. I.e. you better not have any uncommitted
|
||||
changes in your working directory.
|
||||
|
||||
___ Use the release script to create the source gzip and bz2 tarballs, md5
|
||||
checksums, documentation tar and zip files, and gpg signature files.
|
||||
___ Make sure you have an up-to-date Sphinx toolchain installed.
|
||||
|
||||
$ pip install -U Sphinx
|
||||
|
||||
___ Use the release script to create the source gzip and xz tarballs,
|
||||
documentation tar and zip files, and gpg signature files.
|
||||
|
||||
$ .../release/release.py --export X.Y.ZaN
|
||||
|
||||
This will leave all the relevant files in a subdirectory called
|
||||
'X.Y.ZaN/src', and the built docs in 'X.Y.ZaN/docs' (for final releases).
|
||||
This can take a while for final releases, and it will leave all the
|
||||
tarballs and signatures in a subdirectory called 'X.Y.ZaN/src', and the
|
||||
built docs in 'X.Y.ZaN/docs' (for final releases).
|
||||
|
||||
___ scp or rsync all the files to your home directory on dinsdale.python.org.
|
||||
|
||||
|
|
@ -371,7 +349,7 @@ How to Make A Release
|
|||
If you're feeling lucky and have some time to kill, or if you are making
|
||||
a release candidate or final release, run the full test suite:
|
||||
|
||||
$ make TESTOPTS='-u all' test
|
||||
$ make testall
|
||||
|
||||
If the tests pass, then you can feel good that the tarball is
|
||||
fine. If some of the tests fail, or anything else about the
|
||||
|
|
@ -380,7 +358,7 @@ How to Make A Release
|
|||
|
||||
___ Now you need to go to dinsdale.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.
|
||||
directory, but each directory contains all releases of that version.
|
||||
|
||||
___ On dinsdale, cd /data/ftp.python.org/pub/python/X.Y.Z
|
||||
creating it if necessary. Make sure it is owned by group 'webmaster'
|
||||
|
|
@ -409,16 +387,15 @@ How to Make A Release
|
|||
|
||||
___ Let the DE check if the docs are built and work all right.
|
||||
|
||||
___ If this is a major release: Tell the DE to adapt redirects for
|
||||
___ If this is a final major release: Tell the DE to adapt redirects for
|
||||
docs.python.org/X.Y in the Apache config for docs.python.org, update
|
||||
the script Doc/tools/dailybuild.py to point to the right
|
||||
stable/development branches, and to install it and make the initial
|
||||
checkout. The Doc's version_switcher.js script also needs to be
|
||||
updated.
|
||||
|
||||
___ For the extra paranoid, do a completely clean test of the
|
||||
release. This includes downloading the tarball from
|
||||
www.python.org.
|
||||
___ 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,
|
||||
and do a clean make test.
|
||||
|
|
@ -436,9 +413,7 @@ How to Make A Release
|
|||
don't have that, ask someone on pydotorg@python.org for the proper
|
||||
permissions. It's insane for you not to have it.
|
||||
|
||||
I'm not going to go into the details of building the site or pushing it
|
||||
live. All the directories below are named relative to the data subdirectory
|
||||
unless otherwise noted.
|
||||
XXX This is completely out of date for Django based python.org.
|
||||
|
||||
This page will probably come in handy:
|
||||
|
||||
|
|
@ -550,7 +525,7 @@ How to Make A Release
|
|||
|
||||
___ You can delete the remote release clone, or simply reuse it for the next
|
||||
release.
|
||||
|
||||
|
||||
___ Send email to python-committers informing them that the release has been
|
||||
published.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue