Update PEP 101 for this post-blurb world.
This commit is contained in:
Larry Hastings
parent
e648e57384
commit
f197bf4c54
124
pep-0101.txt
124
pep-0101.txt
|
|
@ -35,6 +35,24 @@ Things You'll Need
|
|||
which hopefully will be on the "web of trust" with at least one of
|
||||
the other release managers.
|
||||
|
||||
* A bunch of software:
|
||||
|
||||
* "release.py", the Python release manager's friend. It's in the
|
||||
python/release-tools repo on GitHub. It doesn't pip install
|
||||
or have any sort of install process--you'll have to put it on
|
||||
your path yourself, or just run it with a relative path, or
|
||||
whatever.
|
||||
|
||||
* "blurb", the Misc/NEWS management tool. The release process
|
||||
currently uses three blurb subcommands:
|
||||
release, merge, and export. Installable via pip3.
|
||||
|
||||
* "virtualenv". The release script installs Sphinx in a virtualenv
|
||||
when building the docs (for 2.7 and 3.5+).
|
||||
|
||||
* A fairly complete installation of a recent TeX distribution,
|
||||
such as texlive. You need that for building the PDF docs.
|
||||
|
||||
* Access to ``dl-files.iad1.psf.io``, the server that hosts download files,
|
||||
and ``docs.iad1.psf.io``, the server that hosts the documentation.
|
||||
You'll be uploading files directly here.
|
||||
|
|
@ -164,6 +182,10 @@ How to Make A Release
|
|||
___ Make sure the current branch of your release clone is the branch you
|
||||
want to release from. (``git status``)
|
||||
|
||||
___ Run ``blurb release <version>`` specifying the version number
|
||||
(e.g. ``blurb release 3.4.7rc1``). This merges all the recent news
|
||||
blurbs into a single file marked with this release's version number.
|
||||
|
||||
___ Check the docs for markup errors.
|
||||
|
||||
cd to the Doc directory and run ``make suspicious``. If any markup
|
||||
|
|
@ -232,6 +254,11 @@ How to Make A Release
|
|||
alpha or beta releases. Note that Andrew Kuchling often takes care of
|
||||
this.
|
||||
|
||||
___ Do a "git status" in this directory.
|
||||
|
||||
You should not see any files. I.e. you better not have any uncommitted
|
||||
changes in your working directory.
|
||||
|
||||
___ Tag the release for X.Y.ZaN.
|
||||
|
||||
$ .../release-tools/release.py --tag X.Y.ZaN
|
||||
|
|
@ -294,12 +321,54 @@ How to Make A Release
|
|||
pushed. Login to hg.python.org and edit (as the "hg" user)
|
||||
``/data/hg/repos/cpython/.hg/hgrc`` to that effect.
|
||||
|
||||
___ Do another "git status" in this directory.
|
||||
|
||||
You should not see any files. I.e. you better not have any uncommitted
|
||||
changes in your working directory.
|
||||
|
||||
___ For a final major release, Doc/tools/static/version_switch.js
|
||||
must be updated in all maintained branches, so that the new maintenance
|
||||
branch is not "dev" anymore and there is a new "dev" version.
|
||||
Also, update Doc/tools/templates/indexsidebar.html in all maintained
|
||||
branches.
|
||||
|
||||
___ Time to build the source tarball. Use the release script to create
|
||||
the source gzip and xz tarballs,
|
||||
documentation tar and zip files, and gpg signature files.
|
||||
|
||||
$ .../release-tools/release.py --export X.Y.ZaN
|
||||
|
||||
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).
|
||||
|
||||
___ Now you want to perform the very important step of checking the
|
||||
tarball you just created, to make sure a completely clean,
|
||||
virgin build passes the regression test. Here are the best
|
||||
steps to take:
|
||||
|
||||
$ cd /tmp
|
||||
$ tar xvf /path/to/your/release/clone/<version>//Python-3.2rc2.tgz
|
||||
$ cd Python-3.2rc2
|
||||
$ ls
|
||||
(Do things look reasonable?)
|
||||
$ ls Lib
|
||||
(Are there stray .pyc files?)
|
||||
$ ./configure
|
||||
(Loads of configure output)
|
||||
$ make test
|
||||
(Do all the expected tests pass?)
|
||||
|
||||
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 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
|
||||
freshly unpacked directory looks weird, you better stop now and
|
||||
figure out what the problem is.
|
||||
|
||||
___ Push your commits to the remote release branch in your GitHub fork.
|
||||
|
||||
# Do a dry run first.
|
||||
|
|
@ -360,65 +429,14 @@ How to Make A Release
|
|||
___ The ME builds Mac installer packages and uploads them to
|
||||
dl-files.iad1.psf.io together with gpg signature files.
|
||||
|
||||
___ Time to build the source tarball. Be sure to update your clone to the
|
||||
correct branch. E.g.
|
||||
|
||||
$ git checkout 3.2
|
||||
|
||||
___ Do a "git status" in this directory.
|
||||
|
||||
You should not see any files. I.e. you better not have any uncommitted
|
||||
changes in your working directory.
|
||||
|
||||
___ Make sure you have virtualenv installed (for Python 2.7). The release
|
||||
script installs Sphinx in a virtualenv when building the docs.
|
||||
|
||||
For building the PDF docs, you also need a fairly complete installation
|
||||
of a recent TeX distribution such as texlive.
|
||||
|
||||
___ Use the release script to create the source gzip and xz tarballs,
|
||||
documentation tar and zip files, and gpg signature files.
|
||||
|
||||
$ .../release-tools/release.py --export X.Y.ZaN
|
||||
|
||||
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 dl-files.iad1.psf.io.
|
||||
___ scp or rsync all the files built by ``release.py --export``
|
||||
to your home directory on dl-files.iad1.psf.io.
|
||||
|
||||
While you're waiting for the files to finish uploading, you can continue
|
||||
on with the remaining tasks. You can also ask folks on #python-dev
|
||||
and/or python-committers to download the files as they finish uploading
|
||||
so that they can test them on their platforms as well.
|
||||
|
||||
___ Now you want to perform the very important step of checking the
|
||||
tarball you just created, to make sure a completely clean,
|
||||
virgin build passes the regression test. Here are the best
|
||||
steps to take:
|
||||
|
||||
$ cd /tmp
|
||||
$ tar xvf ~/Python-3.2rc2.tgz
|
||||
$ cd Python-3.2rc2
|
||||
$ ls
|
||||
(Do things look reasonable?)
|
||||
$ ls Lib
|
||||
(Are there stray .pyc files?)
|
||||
$ ./configure
|
||||
(Loads of configure output)
|
||||
$ make test
|
||||
(Do all the expected tests pass?)
|
||||
|
||||
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 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
|
||||
freshly unpacked directory looks weird, you better stop now and
|
||||
figure out what the problem is.
|
||||
|
||||
___ Now you need to go to dl-files.iad1.psf.io and move all the files in place
|
||||
over there. Our policy is that every Python version gets its own
|
||||
directory, but each directory contains all releases of that version.
|
||||
|
|
|
|||
Loading…
Reference in New Issue