Merge pull request #386 from matthew-brett/update-release-list

DOC: update release docs to use `try_branch.py`

Also, remove some emphasis on outdated check scripts.

Author: matthew-brett

doc/source/devel/make_release.rst

@@ -6,26 +6,23 @@ A guide to making a nibabel release
 
 This is a guide for developers who are doing a nibabel release.
 
-.. _release-tools:
-
-Release tools
-=============
-
-There are some release utilities that come with nibabel.  nibabel should
-install these as the ``nisext`` package, and the testing stuff is
-understandably in the ``testers`` module of that package.  nibabel has
-Makefile targets for their use.  The relevant targets are::
-
-    make check-version-info
-    make check-files
-    make sdist-tests
-
-The first installs the code from a git archive, from the repository, and for
-in-place use, and runs the ``get_info()`` function to confirm that
-installation is working and information parameters are set correctly.
-
-The second (``sdist-tests``) makes an sdist source distribution archive,
-installs it to a temporary directory, and runs the tests of that install.
+The general idea of these instructions is to go through the following steps:
+
+* Make sure that the code is in the right state for release;
+* update release-related docs such as the Changelog;
+* update various documents giving dependencies, dates and so on;
+* check all standard and release-specific tests pass;
+* make the *release commit* and release tag;
+* check Windows binary builds and slow / big memory tests;
+* push source and windows builds to pypi;
+* push docs;
+* push release commit and tag to github;
+* announce.
+
+We leave pushing the tag to the last possible moment, because it's very bad
+practice to change a git tag once it has reached the public servers (in our
+case, github).  So we want to make sure of the contents of the release before
+pushing the tag.
 
 .. _release-checklist:
 
@@ -117,8 +114,8 @@ Release checklist
   Fix ``setup.py`` to carry across any files that should be in the
   distribution.
 
-* You probably have virtualenvs for different Python versions.  Check the
-  tests pass for different configurations. The long-hand way looks like this::
+* You may have virtualenvs for different Python versions.  Check the tests
+  pass for different configurations. The long-hand way looks like this::
 
     workon python26
     make distclean
@@ -140,13 +137,51 @@ Release checklist
 
     python -m compileall .
 
-* The release should now be ready.
-
 * Edit ``nibabel/info.py`` to set ``_version_extra`` to ``''``; commit.
   Then::
 
     make source-release
 
+* Make sure you are set up to use the ``try_branch.py`` - see
+  https://github.com/nipy/nibotmi/blob/master/install.rst#trying-a-set-of-changes-on-the-buildbots
+
+* Make sure all your changes are committed or removed, because
+  ``try_branch.py`` pushes up the changes in the working tree;
+
+* Force build of your release candidate branch with the slow and big-memory
+  tests on the ``zibi`` buildslave::
+
+    try_branch.py nibabel-py2.7-osx-10.10
+
+  Check the build web-page for errors:
+
+  * https://nipy.bic.berkeley.edu/builders/nibabel-py2.7-osx-10.10
+
+* Force builds of your local branch on the win32 and amd64 binaries on
+  buildbot::
+
+    try_branch.py nibabel-bdist32-27
+    try_branch.py nibabel-bdist32-34
+    try_branch.py nibabel-bdist32-35
+    try_branch.py nibabel-bdist64-27
+
+  Check the builds completed without error on their respective web-pages:
+
+  * https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-27
+  * https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-34
+  * https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-35
+  * https://nipy.bic.berkeley.edu/builders/nibabel-bdist64-27
+
+  Then get the built binaries in:
+
+  * https://nipy.bic.berkeley.edu/nibabel-dist
+
+  When you've done the release to pypi, you can upload them to pypi with the
+  admin files interface.
+
+  If you are already on a Windows machine, you could have done the manual
+  command to build instead: ``python setup.py bdist_wininst``.
+
 * Once everything looks good, you are ready to upload the source release to
   PyPi.  See `setuptools intro`_.  Make sure you have a file
   ``\$HOME/.pypirc``, of form::
@@ -176,26 +211,13 @@ Release checklist
 
     git push --tags
 
-* Force builds of the win32 and amd64 binaries from the buildbot. Go to pages:
-
-  * https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-27
-  * https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-34
-  * https://nipy.bic.berkeley.edu/builders/nibabel-bdist64-27
-
-  For each of these, enter the revision number (e.g. "2.0.0") in the field
-  "Revision to build". Then get the built binaries in:
-
-  * https://nipy.bic.berkeley.edu/nibabel-dist
-
-  and upload them to pypi with the admin files interface.
-
-  If you are already on a Windows machine, you could have done the manual
-  command to upload instead: ``python setup.py bdist_wininst upload``.
-
 * Now the version number is OK, push the docs to github pages with::
 
     make upload-html
 
+* Finally (for the release uploads) upload the Windows binaries you built with
+  ``try_branch.py`` above;
+
 * Set up maintenance / development branches
 
   If this is this is a full release you need to set up two branches, one for
@@ -221,10 +243,9 @@ Release checklist
     by 1.  Thus the development series ('trunk') will have a version number
     here of '2.1.0.dev' and the next full release will be '2.1.0'.
 
-    Next merge the maintenace branch with the "ours" strategy.  This just
+    Next merge the maintenance branch with the "ours" strategy.  This just
     labels the maintenance `info.py` edits as seen but discarded, so we can
-    merge from maintenance in future without getting spurious merge
-    conflicts::
+    merge from maintenance in future without getting spurious merge conflicts::
 
        git merge -s ours maint/2.0.x