[Python-checkins] peps: Update PEP 101 a bit. Remove outdated Windows instructions.
georg.brandl
python-checkins at python.org
Sun Mar 9 10:01:42 CET 2014
http://hg.python.org/peps/rev/95aaea3e65b0
changeset: 5404:95aaea3e65b0
user: Georg Brandl <georg at python.org>
date: Sun Mar 09 10:01:33 2014 +0100
summary:
Update PEP 101 a bit. Remove outdated Windows instructions.
files:
pep-0101.txt | 95 ++++++++++++++-------------------------
1 files changed, 35 insertions(+), 60 deletions(-)
diff --git a/pep-0101.txt b/pep-0101.txt
--- a/pep-0101.txt
+++ b/pep-0101.txt
@@ -59,7 +59,7 @@
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 at python.org> (Central Europe)
+ * RM = Release Manager: Larry Hastings <larry at hastings.org> (US)
* WE = Windows: Martin von Loewis <martin at v.loewis.de> (Central Europe)
* ME = Mac: Ned Deily <nad at acm.org> (US)
* DE = Docs: Georg Brandl <georg at python.org> (Central Europe)
@@ -70,13 +70,10 @@
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 @@
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 at python.org.
@@ -208,10 +205,6 @@
___ 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 @@
$ 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 @@
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 @@
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 @@
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 @@
___ 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 @@
___ 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 @@
don't have that, ask someone on pydotorg at 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 @@
___ 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.
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list