From ed40f3406f9b70e045d9e55f715368d935845b1b Mon Sep 17 00:00:00 2001 From: Matthew Brett Date: Sat, 21 Nov 2015 18:54:17 -0800 Subject: [PATCH 1/3] DOC: update release docs to use `try_branch.py` Also, remove some emphasis on outdated check scripts. --- doc/source/devel/make_release.rst | 82 ++++++++++++++++--------------- 1 file changed, 43 insertions(+), 39 deletions(-) diff --git a/doc/source/devel/make_release.rst b/doc/source/devel/make_release.rst index 9fda1044e7..f4f5b37ebc 100644 --- a/doc/source/devel/make_release.rst +++ b/doc/source/devel/make_release.rst @@ -6,27 +6,6 @@ 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. - .. _release-checklist: Release checklist @@ -117,8 +96,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,6 +121,44 @@ Release checklist python -m compileall . +* 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-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-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``. + * The release should now be ready. * Edit ``nibabel/info.py`` to set ``_version_extra`` to ``''``; commit. @@ -178,26 +195,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 From b09926c00bc4cda4af1cdb01327afe3b2f4cafb9 Mon Sep 17 00:00:00 2001 From: Matthew Brett Date: Mon, 23 Nov 2015 17:36:09 -0800 Subject: [PATCH 2/3] DOC: move try_branches after release commit Add an introduction to the release procedure. --- doc/source/devel/make_release.rst | 35 ++++++++++++++++++++++--------- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/doc/source/devel/make_release.rst b/doc/source/devel/make_release.rst index f4f5b37ebc..9fb37a5172 100644 --- a/doc/source/devel/make_release.rst +++ b/doc/source/devel/make_release.rst @@ -6,6 +6,24 @@ A guide to making a nibabel release This is a guide for developers who are doing a nibabel release. +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: Release checklist @@ -121,6 +139,11 @@ Release checklist python -m compileall . +* 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 @@ -159,13 +182,6 @@ Release checklist If you are already on a Windows machine, you could have done the manual command to build instead: ``python setup.py bdist_wininst``. -* The release should now be ready. - -* Edit ``nibabel/info.py`` to set ``_version_extra`` to ``''``; commit. - Then:: - - make source-release - * 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:: @@ -227,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 From 7f6aa8e3ee6ac7bf1a5da3f2a29ed12524ddda7e Mon Sep 17 00:00:00 2001 From: Matthew Brett Date: Tue, 24 Nov 2015 18:54:14 -0800 Subject: [PATCH 3/3] DOC: add Python 3.5 buildbots These are working for nibabel, but not when we need a compiler. --- doc/source/devel/make_release.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/source/devel/make_release.rst b/doc/source/devel/make_release.rst index 9fb37a5172..150d5df8b0 100644 --- a/doc/source/devel/make_release.rst +++ b/doc/source/devel/make_release.rst @@ -164,12 +164,14 @@ Release checklist 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: