diff --git a/doc/source/devel/make_release.rst b/doc/source/devel/make_release.rst index 9fda1044e7..150d5df8b0 100644 --- a/doc/source/devel/make_release.rst +++ b/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 @@ -142,13 +139,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:: @@ -178,26 +213,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 @@ -223,10 +245,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