updates
This commit is contained in:
parent
46a946992a
commit
254d2fd256
131
pep-0101.txt
131
pep-0101.txt
|
@ -17,9 +17,9 @@ Abstract
|
||||||
buddies firmly attached to your bare back, anchored by newly sharpened
|
buddies firmly attached to your bare back, anchored by newly sharpened
|
||||||
claws. At least they're cute, you remind yourself.
|
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
|
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
|
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
|
is organized as a recipe and you can actually print this out and check
|
||||||
items off as you complete them.
|
items off as you complete them.
|
||||||
|
@ -38,7 +38,6 @@ How to Make A Release
|
||||||
* RM = Release Manager: Barry Warsaw
|
* RM = Release Manager: Barry Warsaw
|
||||||
* WE = Windows: Martin von Loewis
|
* WE = Windows: Martin von Loewis
|
||||||
* ME = Mac: Ronald Oussoren
|
* ME = Mac: Ronald Oussoren
|
||||||
* DE = Documentation: Fred Drake
|
|
||||||
|
|
||||||
XXX: We should include a dependency graph to illustrate the steps
|
XXX: We should include a dependency graph to illustrate the steps
|
||||||
that can be taken in parallel, or those that depend on other
|
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
|
This helps by performing several automatic editing steps, and guides you
|
||||||
to perform some manual editing steps.
|
to perform some manual editing steps.
|
||||||
|
|
||||||
___ Impose a check-in freeze. Send a message to these mailing lists:
|
___ Log into irc.freenode.net and join the #python-dev channel.
|
||||||
* python-committers@python.org
|
|
||||||
* python-dev@python.org
|
|
||||||
* (Py3: python-3000@python.org)
|
|
||||||
|
|
||||||
telling people not to make any check-ins on the tree until further
|
You probably need to coordinate with other people around the
|
||||||
notice.
|
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
|
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
|
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.
|
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.
|
___ Check to see if there are any showstopper bugs.
|
||||||
|
|
||||||
Go to http://bugs.python.org and look for any open bugs that can block
|
Go to http://bugs.python.org and look for any open bugs that can block
|
||||||
|
@ -96,13 +89,19 @@ How to Make A Release
|
||||||
release blocker - Stops the release dead in its tracks. You may not
|
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
|
deferred blocker - Doesn't block this release, but it will block a
|
||||||
release. You can make alpha and beta releases with open critical
|
future release.
|
||||||
bugs, but you may not make a final release with open critical bugs.
|
|
||||||
|
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
|
Review the release blockers and either resolve them, bump them down to
|
||||||
critical, or stop the release and ask for community assistance. If
|
deferred, or stop the release and ask for community assistance. If
|
||||||
you're making a final release, do the same with any open crticial bugs.
|
you're making a final release, do the same with any open deferred and
|
||||||
|
crticial bugs.
|
||||||
|
|
||||||
___ Check the stable buildbots.
|
___ 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,
|
___ The LICENSE file. Add the pending version to the list of releases,
|
||||||
and be sure to check the release dates.
|
and be sure to check the release dates.
|
||||||
|
|
||||||
___ There's a copy of the license in Doc/license.rst; the DE usually
|
___ There's a copy of the license in Doc/license.rst
|
||||||
takes care of that, but it's good to double check this.
|
|
||||||
|
|
||||||
___ Doc/tutorial/interpreter.rst (3 references to '[Pp]ython26', one
|
___ Doc/tutorial/interpreter.rst (3 references to '[Pp]ython26', one
|
||||||
to 'Python 2.6').
|
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>
|
___ XXX If this is a release candidate, mail Sean <jafo@tummy.com>
|
||||||
noting the impending release, so that RPMs can be built and tested.
|
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
|
___ XXX The WE builds the Windows helpfile, using (in Doc/) either
|
||||||
|
|
||||||
$ make htmlhelp (on Unix)
|
$ make htmlhelp (on Unix)
|
||||||
|
|
Loading…
Reference in New Issue