@@ -6,26 +6,23 @@ A guide to making a nibabel release
6
6
7
7
This is a guide for developers who are doing a nibabel release.
8
8
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.
29
26
30
27
.. _release-checklist :
31
28
@@ -117,8 +114,8 @@ Release checklist
117
114
Fix ``setup.py `` to carry across any files that should be in the
118
115
distribution.
119
116
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::
122
119
123
120
workon python26
124
121
make distclean
@@ -140,13 +137,51 @@ Release checklist
140
137
141
138
python -m compileall .
142
139
143
- * The release should now be ready.
144
-
145
140
* Edit ``nibabel/info.py `` to set ``_version_extra `` to ``'' ``; commit.
146
141
Then::
147
142
148
143
make source-release
149
144
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
+
150
185
* Once everything looks good, you are ready to upload the source release to
151
186
PyPi. See `setuptools intro `_. Make sure you have a file
152
187
``\$HOME/.pypirc ``, of form::
@@ -176,26 +211,13 @@ Release checklist
176
211
177
212
git push --tags
178
213
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
-
195
214
* Now the version number is OK, push the docs to github pages with::
196
215
197
216
make upload-html
198
217
218
+ * Finally (for the release uploads) upload the Windows binaries you built with
219
+ ``try_branch.py `` above;
220
+
199
221
* Set up maintenance / development branches
200
222
201
223
If this is this is a full release you need to set up two branches, one for
@@ -221,10 +243,9 @@ Release checklist
221
243
by 1. Thus the development series ('trunk') will have a version number
222
244
here of '2.1.0.dev' and the next full release will be '2.1.0'.
223
245
224
- Next merge the maintenace branch with the "ours" strategy. This just
246
+ Next merge the maintenance branch with the "ours" strategy. This just
225
247
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::
228
249
229
250
git merge -s ours maint/2.0.x
230
251
0 commit comments