From f197bf4c54405ca0f13554c70e14d89ae684b741 Mon Sep 17 00:00:00 2001 From: Larry Hastings Date: Sun, 23 Jul 2017 20:25:16 -0700 Subject: [PATCH] Update PEP 101 for this post-blurb world. --- pep-0101.txt | 124 +++++++++++++++++++++++++++++---------------------- 1 file changed, 71 insertions(+), 53 deletions(-) diff --git a/pep-0101.txt b/pep-0101.txt index 8292ac456..8854b9591 100644 --- a/pep-0101.txt +++ b/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 `` 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///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.