44
* Review the open list of `issues <http://github.com/nipy/nibabel/issues>`_ .
45
Check whether there are outstanding issues that can be closed, and whether
46
there are any issues that should delay the release. Label them !
42
* Review the open list of `nibabel issues`_. Check whether there are
43
outstanding issues that can be closed, and whether there are any issues that
44
should delay the release. Label them !
48
46
* Review and update the release notes. Review and update the :file:`Changelog`
49
47
file. Get a partial list of contributors with something like::
51
git log 0.9.0.. | grep '^Author' | cut -d' ' -f 2- | sort | uniq
53
where ``0.9.0`` was the last release tag name.
55
Then manually go over the *git log* to make sure the release notes are
56
as complete as possible and that every contributor was recognized.
49
git log 1.2.0.. | grep '^Author' | cut -d' ' -f 2- | sort | uniq
51
where ``1.2.0`` was the last release tag name.
53
Then manually go over ``git shortlog 1.2.0..`` to make sure the release notes
54
are as complete as possible and that every contributor was recognized.
56
* Use the opportunity to update the ``.mailmap`` file if there are any duplicate
57
authors listed from ``git shortlog``.
58
59
* Check the ``long_description`` in ``nibabel/info.py``. Check it matches the
59
60
``README`` in the root directory.
62
* Do a final check on the `nipy buildbot`_
64
* If you have travis-ci_ building set up you might want to push the code in it's
65
current state to a branch that will build, e.g::
67
git branch -D pre-release-test # in case branch already exists
68
git co -b pre-release-test
69
git push origin pre-release-test
130
For the PPC I have to log into an old Mac G5 in Berkeley. It doesn't have a
131
fixed IP even, but here's an example session::
140
For the PPC I have to log into an old Mac G5 in Berkeley at
141
``jerry.bic.berkeley.edu``. Here's an example session::
143
ssh jerry.bic.berkeley.edu
134
144
cd dev_trees/nibabel
135
145
git co main-master
154
164
make source-release
156
* Once everything looks good, upload the source release to PyPi. Also upload a
157
Windows exe installer for convenience. See `setuptools intro`_::
166
* Once everything looks good, upload the source release to PyPi. See
167
`setuptools intro`_::
159
169
python setup.py register
160
170
python setup.py sdist --formats=gztar,zip upload
172
From somewhere - maybe a windows machine - upload the windows installer for
161
175
python setup.py bdist_wininst upload
163
177
* Tag the release with tag of form ``1.1.0``::
213
227
This tag is used in the Makefile rules to create development snapshot
214
228
releases to create proper versions for those. The version derives its name
215
229
from the last available annotated tag, the number of commits since that, and
216
an abbrevated SHA1. See the docs of ``git describe`` for more info.
230
an abbreviated SHA1. See the docs of ``git describe`` for more info.
218
232
Please take a look at the Makefile rules ``devel-src``,
219
233
``devel-dsc`` and ``orig-src``.
added
removed
doc/source/devel/make_release.rst
