Skip to content

Commit 588c8f0

Browse files
committed
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.
2 parents 0f7f2a9 + 7f6aa8e commit 588c8f0

File tree

1 file changed

+64
-43
lines changed

1 file changed

+64
-43
lines changed

doc/source/devel/make_release.rst

Lines changed: 64 additions & 43 deletions
Original file line numberDiff line numberDiff line change
@@ -6,26 +6,23 @@ A guide to making a nibabel release
66

77
This is a guide for developers who are doing a nibabel release.
88

9-
.. _release-tools:
10-
11-
Release tools
12-
=============
13-
14-
There are some release utilities that come with nibabel. nibabel should
15-
install these as the ``nisext`` package, and the testing stuff is
16-
understandably in the ``testers`` module of that package. nibabel has
17-
Makefile targets for their use. The relevant targets are::
18-
19-
make check-version-info
20-
make check-files
21-
make sdist-tests
22-
23-
The first installs the code from a git archive, from the repository, and for
24-
in-place use, and runs the ``get_info()`` function to confirm that
25-
installation is working and information parameters are set correctly.
26-
27-
The second (``sdist-tests``) makes an sdist source distribution archive,
28-
installs it to a temporary directory, and runs the tests of that install.
9+
The general idea of these instructions is to go through the following steps:
10+
11+
* Make sure that the code is in the right state for release;
12+
* update release-related docs such as the Changelog;
13+
* update various documents giving dependencies, dates and so on;
14+
* check all standard and release-specific tests pass;
15+
* make the *release commit* and release tag;
16+
* check Windows binary builds and slow / big memory tests;
17+
* push source and windows builds to pypi;
18+
* push docs;
19+
* push release commit and tag to github;
20+
* announce.
21+
22+
We leave pushing the tag to the last possible moment, because it's very bad
23+
practice to change a git tag once it has reached the public servers (in our
24+
case, github). So we want to make sure of the contents of the release before
25+
pushing the tag.
2926

3027
.. _release-checklist:
3128

@@ -117,8 +114,8 @@ Release checklist
117114
Fix ``setup.py`` to carry across any files that should be in the
118115
distribution.
119116

120-
* You probably have virtualenvs for different Python versions. Check the
121-
tests pass for different configurations. The long-hand way looks like this::
117+
* You may have virtualenvs for different Python versions. Check the tests
118+
pass for different configurations. The long-hand way looks like this::
122119

123120
workon python26
124121
make distclean
@@ -140,13 +137,51 @@ Release checklist
140137

141138
python -m compileall .
142139

143-
* The release should now be ready.
144-
145140
* Edit ``nibabel/info.py`` to set ``_version_extra`` to ``''``; commit.
146141
Then::
147142

148143
make source-release
149144

145+
* Make sure you are set up to use the ``try_branch.py`` - see
146+
https://github.com/nipy/nibotmi/blob/master/install.rst#trying-a-set-of-changes-on-the-buildbots
147+
148+
* Make sure all your changes are committed or removed, because
149+
``try_branch.py`` pushes up the changes in the working tree;
150+
151+
* Force build of your release candidate branch with the slow and big-memory
152+
tests on the ``zibi`` buildslave::
153+
154+
try_branch.py nibabel-py2.7-osx-10.10
155+
156+
Check the build web-page for errors:
157+
158+
* https://nipy.bic.berkeley.edu/builders/nibabel-py2.7-osx-10.10
159+
160+
* Force builds of your local branch on the win32 and amd64 binaries on
161+
buildbot::
162+
163+
try_branch.py nibabel-bdist32-27
164+
try_branch.py nibabel-bdist32-34
165+
try_branch.py nibabel-bdist32-35
166+
try_branch.py nibabel-bdist64-27
167+
168+
Check the builds completed without error on their respective web-pages:
169+
170+
* https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-27
171+
* https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-34
172+
* https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-35
173+
* https://nipy.bic.berkeley.edu/builders/nibabel-bdist64-27
174+
175+
Then get the built binaries in:
176+
177+
* https://nipy.bic.berkeley.edu/nibabel-dist
178+
179+
When you've done the release to pypi, you can upload them to pypi with the
180+
admin files interface.
181+
182+
If you are already on a Windows machine, you could have done the manual
183+
command to build instead: ``python setup.py bdist_wininst``.
184+
150185
* Once everything looks good, you are ready to upload the source release to
151186
PyPi. See `setuptools intro`_. Make sure you have a file
152187
``\$HOME/.pypirc``, of form::
@@ -176,26 +211,13 @@ Release checklist
176211

177212
git push --tags
178213

179-
* Force builds of the win32 and amd64 binaries from the buildbot. Go to pages:
180-
181-
* https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-27
182-
* https://nipy.bic.berkeley.edu/builders/nibabel-bdist32-34
183-
* https://nipy.bic.berkeley.edu/builders/nibabel-bdist64-27
184-
185-
For each of these, enter the revision number (e.g. "2.0.0") in the field
186-
"Revision to build". Then get the built binaries in:
187-
188-
* https://nipy.bic.berkeley.edu/nibabel-dist
189-
190-
and upload them to pypi with the admin files interface.
191-
192-
If you are already on a Windows machine, you could have done the manual
193-
command to upload instead: ``python setup.py bdist_wininst upload``.
194-
195214
* Now the version number is OK, push the docs to github pages with::
196215

197216
make upload-html
198217

218+
* Finally (for the release uploads) upload the Windows binaries you built with
219+
``try_branch.py`` above;
220+
199221
* Set up maintenance / development branches
200222

201223
If this is this is a full release you need to set up two branches, one for
@@ -221,10 +243,9 @@ Release checklist
221243
by 1. Thus the development series ('trunk') will have a version number
222244
here of '2.1.0.dev' and the next full release will be '2.1.0'.
223245

224-
Next merge the maintenace branch with the "ours" strategy. This just
246+
Next merge the maintenance branch with the "ours" strategy. This just
225247
labels the maintenance `info.py` edits as seen but discarded, so we can
226-
merge from maintenance in future without getting spurious merge
227-
conflicts::
248+
merge from maintenance in future without getting spurious merge conflicts::
228249

229250
git merge -s ours maint/2.0.x
230251

0 commit comments

Comments
 (0)