- update some of the documentation build/release steps
- replace all occurances of "creosote" with "dinsdale"
This commit is contained in:
Fred Drake
parent
4c8c08686b
commit
2ad9f52224
122
pep-0101.txt
122
pep-0101.txt
|
|
@ -197,7 +197,7 @@ How to Make A Release
|
|||
|
||||
___ Python/getcopyright.c
|
||||
|
||||
___ Doc/README
|
||||
___ Doc/README (at the end)
|
||||
|
||||
___ Doc/commontex/copyright.tex
|
||||
|
||||
|
|
@ -251,8 +251,8 @@ How to Make A Release
|
|||
$ scp *-$VERSION.* dinsdale.python.org:$TARGET
|
||||
|
||||
___ For final releases, publish the documentation on python.org.
|
||||
This must be done by someone with write access to the python.org
|
||||
CVS repository.
|
||||
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
|
||||
|
|
@ -260,43 +260,30 @@ How to Make A Release
|
|||
version on the site.
|
||||
|
||||
$ cd .../pydotorg/doc/
|
||||
$ mkdir $VERSION
|
||||
$ cvs add $VERSION
|
||||
$ svn mkdir $VERSION $VERSION/download
|
||||
$ cd $OLDVERSION
|
||||
$ cp .cvsignore Makefile index.ht download.ht ../$VERSION
|
||||
$ cd ../$VERSION
|
||||
$ cvs add .cvsignore Makefile *.ht
|
||||
$ 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
|
||||
|
||||
Now make the following edits:
|
||||
In $VERSION/content.rst and $VERSION/download/content.rst, change:
|
||||
|
||||
- in Makefile, change the value of ROOT_OFFSET to doc/$VERSION
|
||||
- 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 index.ht, change:
|
||||
- the version number to $VERSION in two places: the Title:
|
||||
header, and the <h3> at the top of the page
|
||||
- the release date, in the <h3> at the top of the page
|
||||
- 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")
|
||||
In $VERSION/index.yml and $VERSION/download/index.yml, change
|
||||
the version number in the title.
|
||||
|
||||
- in download.ht, change:
|
||||
- the version number to $VERSION in two places: the Title:
|
||||
header, and the <h3> at the top of the page
|
||||
- the release date, in the <h3> at the top of the page
|
||||
- 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")
|
||||
- replace the large table of downloads with the content of the
|
||||
pkglist.html file generated by the documentation build
|
||||
process
|
||||
In versions/content.rst, add an entry for the new version near
|
||||
the top.
|
||||
|
||||
Now, the web content has all been prepared, but there's still
|
||||
some dancing to do to make it all work right. To be safe, we
|
||||
can commit the new files to CVS, but we're *not* ready to
|
||||
install them on the site yet:
|
||||
|
||||
$ cvs commit -m \
|
||||
"Add website content for Python $VERSION documentation."
|
||||
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:
|
||||
|
|
@ -308,32 +295,21 @@ How to Make A Release
|
|||
$ mv Python-Docs-$VERSION $VERSION
|
||||
$ find $VERSION -type d | xargs chmod g+s
|
||||
|
||||
Now head back to your pydotorg checkout on your workstation, and
|
||||
push website content into place:
|
||||
Now head back to your pydotorg checkout and commit the changes
|
||||
so the site will be updated:
|
||||
|
||||
$ cd .../pydotorg/doc/$VERSION
|
||||
$ make install
|
||||
$ 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 are three more changes that need to happen in the
|
||||
top-level doc/ directory of the website content. The first of
|
||||
these can happen any time after what's already happened in this
|
||||
process, and the last two should happen as soon as the release
|
||||
announcement has been made. Those are described in a separate
|
||||
step of this checklist.
|
||||
|
||||
At this time, edit the versions.ht file in doc/ to make add the
|
||||
new release at the top. The previous latest release should drop
|
||||
down to the top of the long list of released versions, and the
|
||||
new release should replace the previous most recent release.
|
||||
There should be a blank line between the link to the development
|
||||
documentation and the most recent release, and another blank
|
||||
line between the most recent release and the long list of older
|
||||
releases. (Is should be fairly easy to figure this out while
|
||||
looking at the file.)
|
||||
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.
|
||||
|
||||
___ Martin grabs the HTML to build the Windows helpfile.
|
||||
The HTML files are unpacked into a new src/html directory, and
|
||||
|
|
@ -343,7 +319,7 @@ How to Make A Release
|
|||
% python ..\Doc\tools\prechm.py -v 2.5 python25
|
||||
|
||||
HTML Workshop is then fired up on the created python25.hhp file,
|
||||
finally resulting in an python25.chm file. He then copies the
|
||||
finally resulting in an python25.chm file. He then copies the
|
||||
file into the Doc directories of the build trees (once for
|
||||
each target architecture).
|
||||
|
||||
|
|
@ -364,9 +340,8 @@ How to Make A Release
|
|||
architecture in its path (VS 2003 for x86, the platform
|
||||
SDK for Itanium and AMD64).
|
||||
|
||||
Martin checksums the files (*.msi and *.chm), uploads them
|
||||
to some place in the net, and emails you the location
|
||||
and md5sums.
|
||||
Martin checksums the files (*.msi and *.chm), uploads them to
|
||||
some place in the net, and emails you the location and md5sums.
|
||||
|
||||
___ Sean Reifschneider grabs the HTML and uses this to build the
|
||||
Linux RPMs. Sean performs his Red Hat magic, generating a set
|
||||
|
|
@ -447,7 +422,7 @@ How to Make A Release
|
|||
freshly unpacked directory looks weird, you better stop now and
|
||||
figure out what the problem is.
|
||||
|
||||
___ Upload the tgz file to creosote.python.org using scp.
|
||||
___ Upload the tgz file to dinsdale.python.org using scp.
|
||||
|
||||
___ While you're waiting, you can start twiddling the web pages to
|
||||
include the announcement.
|
||||
|
|
@ -456,7 +431,7 @@ How to Make A Release
|
|||
python.org sysadmins must set this up for you), check out the
|
||||
web site CVS tree by doing:
|
||||
|
||||
% cvs -d :ext:<you>@creosote.python.org:/usr/local/cvsroot co pydotorg
|
||||
% cvs -d :ext:<you>@dinsdale.python.org:/usr/local/cvsroot co pydotorg
|
||||
|
||||
___ In the python.org web site CVS tree, cd to the X.Y
|
||||
subdirectory, and copy index.ht to new-index.ht. Be sure to
|
||||
|
|
@ -491,10 +466,10 @@ How to Make A Release
|
|||
correct. Update the links in the left-hand navigation
|
||||
sidebar. Still do NOT do a "make install"!
|
||||
|
||||
___ Now we're waiting for the scp to creosote to finish. Da de da,
|
||||
___ Now we're waiting for the scp to dinsdale to finish. Da de da,
|
||||
da de dum, hmm, hmm, dum de dum.
|
||||
|
||||
___ Now you need to go to creosote.python.org and move all the files
|
||||
___ 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. We keep all old releases, moving them into a "prev"
|
||||
|
|
@ -506,7 +481,7 @@ How to Make A Release
|
|||
|
||||
So...
|
||||
|
||||
___ On creosote, cd to ~ftp/pub/python/X.Y creating it if
|
||||
___ On dinsdale, cd to ~ftp/pub/python/X.Y creating it if
|
||||
necessary.
|
||||
|
||||
___ Move the previous release files to a directory called "prev"
|
||||
|
|
@ -559,27 +534,18 @@ How to Make A Release
|
|||
|
||||
Feel free to remove any old news items.
|
||||
|
||||
___ Make the last two changes to the documentation area on
|
||||
___ Make the last change to the documentation area on
|
||||
python.org. (Remember those from the documentation items above?
|
||||
It's time now.)
|
||||
|
||||
In your pydotorg checkout, edit the file doc/index.ht to update
|
||||
to the right version number and release date. Commit the
|
||||
changes to CVS and push the file to the website:
|
||||
The "current" symlink needs to be updated if this release is the
|
||||
highest-versioned release. Log in to dinsdale.python.org, and
|
||||
update a symlink in the doc/ tree:
|
||||
|
||||
$ cd .../pydotorg/doc/
|
||||
$ make install
|
||||
|
||||
This will cause the doc/index.html file to claim to point to the
|
||||
new docs, but they won't. Run (don't walk!) to
|
||||
creosote.python.org, and update a symlink in the doc/ tree:
|
||||
|
||||
# on creosote:
|
||||
$ cd /ftp/www.python.org/doc/
|
||||
# on dinsdale:
|
||||
$ cd /data/ftp.python.org/pub/www.python.org/doc/
|
||||
$ rm current && ln -s $VERSION current
|
||||
|
||||
Good. Stop running.
|
||||
|
||||
Now it's time to do some cleaning up. These steps are very important!
|
||||
|
||||
___ If you made a non-maintenance branch, be sure to merge it into
|
||||
|
|
|
|||
Loading…
Reference in New Issue