Skip to content

DOC: update release docs to use try_branch.py #386

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Nov 29, 2015
Merged

DOC: update release docs to use try_branch.py #386

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ed40f34
DOC: update release docs to use `try_branch.py`
matthew-brett Nov 22, 2015
b09926c
DOC: move try_branches after release commit
matthew-brett Nov 24, 2015
7f6aa8e
DOC: add Python 3.5 buildbots
matthew-brett Nov 25, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
107 changes: 64 additions & 43 deletions doc/source/devel/make_release.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down Expand Up @@ -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
Expand All @@ -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``.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this makes sense to move to below the release commit, otherwise you end up with x.y.z.dev binaries. I ended up doing this sequence:

  • Update docs and nibabel/info.py on a PR branch
  • Merge PR in Github
  • Pull maint/2.0.x, tag and push tag
  • Push to pypi
  • Push to buildbots

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, you're right. But I personally like to avoid pushing the tag for as long as possible because it can't be reversed after. So I suggest try_branch pushing to the buildbots after the release commit, but before pushing the release commit or the release tag.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked the builds on the branch that had been merged in before tagging, but that's a good policy.

* 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::
Expand Down Expand Up @@ -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
Expand All @@ -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

Expand Down