Update PEP 101 for Doc changes, as far as I know things (left the website stuff untouched).
Note that "make distribution" doesn't work yet; will write that before the next alpha.
This commit is contained in:
parent
7cf4900344
commit
b8e9fcb776
65
pep-0101.txt
65
pep-0101.txt
|
@ -110,7 +110,7 @@ How to Make A Release
|
|||
Lib/idlelib/NEWS.txt has been similarly updated.
|
||||
|
||||
___ Make sure the release date is fully spelled out in
|
||||
Doc/commontex/boilerplate.tex (welease). BROKEN
|
||||
Doc/conf.py (setting 'today') (XXX update welease).
|
||||
|
||||
___ Tag and/or branch the tree for release X.YaZ (welease does tagging)
|
||||
|
||||
|
@ -195,15 +195,19 @@ How to Make A Release
|
|||
___ Update the README file, which has a big banner at the top
|
||||
proclaiming its identity.
|
||||
|
||||
___ If the major (first) or minor (middle) digit of the version
|
||||
number changes, also update the LICENSE file.
|
||||
___ Also update the LICENSE file, adding the pending version to the
|
||||
list of releases.
|
||||
|
||||
___ There's a copy of the license in
|
||||
Doc/commontex/license.tex; the DE usually takes care of that. BROKEN
|
||||
Doc/license.rst; the DE usually takes care of that.
|
||||
|
||||
___ If the minor (middle) digit of the version number changes, update:
|
||||
|
||||
___ Doc/tut/tut.tex (4 references to [Pp]ython26) BROKEN
|
||||
___ Doc/tutorial/interpreter.rst (3 references to '[Pp]ython26', one
|
||||
to 'Python 2.6').
|
||||
|
||||
___ Doc/tutorial/stdlib.rst and Doc/tutorial/stdlib2.rst, which have
|
||||
each one reference to '[Pp]ython26'.
|
||||
|
||||
___ Check the years on the copyright notice. If the last release
|
||||
was some time last year, add the current year to the copyright
|
||||
|
@ -215,11 +219,11 @@ How to Make A Release
|
|||
|
||||
___ Python/getcopyright.c
|
||||
|
||||
___ Doc/README (at the end)
|
||||
___ Doc/README.txt (at the end)
|
||||
|
||||
___ Doc/commontex/copyright.tex BROKEN
|
||||
___ Doc/copyright.rst
|
||||
|
||||
___ Doc/commontex/license.tex BROKEN
|
||||
___ Doc/license.rst
|
||||
|
||||
___ PC/python_nt.rc sets up the DLL version resource for Windows
|
||||
(displayed when you right-click on the DLL and select
|
||||
|
@ -230,7 +234,7 @@ How to Make A Release
|
|||
file from the distribution. BROKEN
|
||||
|
||||
___ For a final release, edit the first paragraph of
|
||||
Doc/whatsnew/whatsnewXX.tex to include the actual release date;
|
||||
Doc/whatsnew/X.Y.rst to include the actual release date;
|
||||
e.g. "Python 2.5 was released on August 1, 2003."
|
||||
There's no need to edit this for alpha or beta releases. Note
|
||||
that Andrew Kuchling often takes care of this.
|
||||
|
@ -247,26 +251,19 @@ How to Make A Release
|
|||
branch in the Doc/ directory -- not even by the RM.
|
||||
|
||||
Building the documentation is done using the Makefile in the
|
||||
Doc/ directory. Once all the external tools are installed (see
|
||||
the "Documenting Python" manual for information on the required
|
||||
tools), use these commands to build the formatted documentation
|
||||
packages::
|
||||
Doc/ directory. Use these commands to build the formatted
|
||||
documentation packages:
|
||||
|
||||
$ make clobber
|
||||
...
|
||||
$ make PAPER=a4 paperdist
|
||||
...
|
||||
$ make distfiles
|
||||
...
|
||||
$ make clean
|
||||
$ make distribution
|
||||
|
||||
The packages can be installed on the FTP server using commands
|
||||
like these:
|
||||
The packages in build/distribution can be installed on the
|
||||
FTP server using commands like these:
|
||||
|
||||
$ VERSION=`tools/getversioninfo`
|
||||
$ VERSION=`python tools/sphinxext/patchlevel.py`
|
||||
$ TARGET=/data/python-releases/doc/$VERSION
|
||||
$ rm *-$VERSION.tar
|
||||
$ ssh dinsdale.python.org mkdir $TARGET
|
||||
$ scp *-$VERSION.* dinsdale.python.org:$TARGET
|
||||
$ scp build/distribution/* dinsdale.python.org:$TARGET
|
||||
|
||||
___ For final releases, publish the documentation on python.org.
|
||||
This must be done by someone with write access to the pydotorg
|
||||
|
@ -333,17 +330,19 @@ How to Make A Release
|
|||
which runs the automated builds) to fix conflicts that arise
|
||||
in the checked out working areas.
|
||||
|
||||
___ The WE grabs the HTML to build the Windows helpfile.
|
||||
The HTML files are unpacked into a new src/html directory, and
|
||||
runs this command to create the project files for MS HTML
|
||||
Workshop:
|
||||
___ The WE builds the Windows helpfile, using (in Doc/) either
|
||||
|
||||
$ make htmlhelp (on Unix)
|
||||
|
||||
% python ..\Doc\tools\prechm.py -v 2.6 python26
|
||||
or
|
||||
|
||||
HTML Workshop is then fired up on the created python25.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).
|
||||
> 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).
|
||||
|
||||
___ The WE then generates Windows installer files for each Windows
|
||||
target architecture (for Python 2.6, this means x86
|
||||
|
|
Loading…
Reference in New Issue