iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

updates

This commit is contained in:
Barry Warsaw 2008-09-13 00:22:56 +00:00
parent 46a946992a
commit 254d2fd256
1 changed files with 20 additions and 113 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

133
pep-0101.txt
View File

@ -17,9 +17,9 @@ Abstract
buddies firmly attached to your bare back, anchored by newly sharpened
claws. At least they're cute, you remind yourself.
Actually, no that's a slight <wink> exaggeration. The Python release
Actually, no that's a slight exaggeration <wink>. The Python release
process has steadily improved over the years and now, with the help of our
amazing community, is really not to difficult. This PEP attempts to
amazing community, is really not too difficult. This PEP attempts to
collect, in one place, all the steps needed to make a Python release. It
is organized as a recipe and you can actually print this out and check
items off as you complete them.
@ -38,7 +38,6 @@ How to Make A Release
* RM = Release Manager: Barry Warsaw
* WE = Windows: Martin von Loewis
* ME = Mac: Ronald Oussoren
* DE = Documentation: Fred Drake
XXX: We should include a dependency graph to illustrate the steps
that can be taken in parallel, or those that depend on other
@ -64,13 +63,12 @@ How to Make A Release
This helps by performing several automatic editing steps, and guides you
to perform some manual editing steps.
___ Impose a check-in freeze. Send a message to these mailing lists:
* python-committers@python.org
* python-dev@python.org
* (Py3: python-3000@python.org)
___ Log into irc.freenode.net and join the #python-dev channel.
telling people not to make any check-ins on the tree until further
notice.
You probably need to coordinate with other people around the
world. This IRC channel is where we've arranged to meet.
___ Impose a check-in freeze by sending email to python-committers@python.org
At this point, nobody except the RM or his duly assigned agents should
make any commits to the branches. The assigned agents are either from
@ -82,11 +80,6 @@ How to Make A Release
The RM has full authority to revert any unapproved commits.
___ Log into irc.freenode.net and join the #python-dev channel.
You probably need to coordinate with other people around the
world. This IRC channel is where we've arranged to meet.
___ Check to see if there are any showstopper bugs.
Go to http://bugs.python.org and look for any open bugs that can block
@ -94,15 +87,21 @@ How to Make A Release
release you're making; here are the relevant definitions:
release blocker - Stops the release dead in its tracks. You may not
make a release with any open blocker bugs.
make a release with any open blocker bugs.
critical - Important bugs that may become blockers for the next
release. You can make alpha and beta releases with open critical
bugs, but you may not make a final release with open critical bugs.
deferred blocker - Doesn't block this release, but it will block a
future release.
critical - Important bugs that should be fixed before the next release,
but which won't block a non-final release.
You can make alpha and beta releases with open critical bugs, but you
may not make a final release with open critical bugs.
Review the release blockers and either resolve them, bump them down to
critical, or stop the release and ask for community assistance. If
you're making a final release, do the same with any open crticial bugs.
deferred, or stop the release and ask for community assistance. If
you're making a final release, do the same with any open deferred and
crticial bugs.
___ Check the stable buildbots.
@ -136,8 +135,7 @@ How to Make A Release
___ The LICENSE file. Add the pending version to the list of releases,
and be sure to check the release dates.
___ There's a copy of the license in Doc/license.rst; the DE usually
takes care of that, but it's good to double check this.
___ There's a copy of the license in Doc/license.rst
___ Doc/tutorial/interpreter.rst (3 references to '[Pp]ython26', one
to 'Python 2.6').
@ -205,97 +203,6 @@ How to Make A Release
___ XXX If this is a release candidate, mail Sean <jafo@tummy.com>
noting the impending release, so that RPMs can be built and tested.
___ XXX At this point, the DE will create the formatted versions of the
documentation and push the appropriate files out to their FTP
locations on www.python.org. The HTML format is used to build
the HTML Help format for the Windows installer, but the RM
doesn't need this to build the source distribution. The HTML
Help format will typically be generated by whoever builds the
Windows installer.
Once the DE is done, there can be no further checkins on the
branch in the Doc/ directory -- not even by the RM.
Building the documentation is done using the Makefile in the
Doc/ directory. Use these commands to build the formatted
documentation packages:
$ make clean
$ make distribution
The packages in build/distribution can be installed on the
FTP server using commands like these:
$ VERSION=`python tools/sphinxext/patchlevel.py`
$ TARGET=/data/python-releases/doc/$VERSION
$ ssh dinsdale.python.org mkdir $TARGET
$ scp build/distribution/* dinsdale.python.org:$TARGET
___ XXX For final releases, publish the documentation on python.org.
This must be done by someone with write access to the pydotorg
repository.
Start by creating a new directory and filling it with the
standard boilerplate. $VERSION is the same as for uploading the
documentation, above; $OLDVERSION is the most recently published
version on the site.
$ cd .../pydotorg/doc/
$ svn mkdir $VERSION $VERSION/download
$ cd $OLDVERSION
$ svn cp content.{html,rst,yml} index.yml nav.yml ../$VERSION
$ cd download
$ svn cp content.{html,rst,yml} index.yml nav.yml ../$VERSION/download
$ cd ../../$VERSION
In $VERSION/content.rst and $VERSION/download/content.rst, change:
- in the header at the top of the page, update to reflect
the version number and release date
- if the minor release number changed (for example, from 2.5
to 2.6), the title and link to the "What's New" document
(search for "whatsnew")
- make sure all the documents included in the package are listed
In $VERSION/index.yml and $VERSION/download/index.yml, change
the version number in the title.
In versions/content.rst, add an entry for the new version near
the top.
Use the "rst2html" command (commonly installed with docutils) to
ensure that the .rst files can be formatted without errors.
Log into dinsdale.python.org using SSH and unpack a copy of the
documentation into place:
# on dinsdale:
$ cd /data/ftp.python.org/pub/www.python.org/doc
$ bzip2 -dc /data/python-releases/doc/$VERSION/html-$VERSION.tar.bz2 \
| tar xf -
$ mv Python-Docs-$VERSION $VERSION
$ find $VERSION -type d | xargs chmod g+s
Now head back to your pydotorg checkout and commit the changes
so the site will be updated:
$ svn commit -m \
"Add website content for Python $VERSION documentation."
Point your browser at this URL and check it out:
http://www.python.org/doc/$VERSION/
There is one more change that may need to happen in the
top-level doc/ directory of the website content. This should
happen as soon as the release announcement has been made. The
required actions are described in a separate step of this
checklist.
___ XXX Ping Neal Norwitz (or anyone else with access to the PSF box
which runs the automated builds) to fix conflicts that arise
in the checked out working areas.
___ XXX The WE builds the Windows helpfile, using (in Doc/) either
$ make htmlhelp (on Unix)