A guide to making a nipy release¶
A guide for developers who are doing a nipy release
Release checklist¶
Review the open list of nipy issues. Check whether there are outstanding issues that can be closed, and whether there are any issues that should delay the release. Label them !
Review and update the release notes. Review and update the
Changelog
file. Get a partial list of contributors with something like:PREV_RELEASE=0.5.0 git log $PREV_RELEASE.. | grep '^Author' | cut -d' ' -f 2- | sort | uniq
where
0.5.0
was the last release tag name.Then manually go over
git shortlog $PREV_RELEASE..
to make sure the release notes are as complete as possible and that every contributor was recognized.Use the opportunity to update the
.mailmap
file if there are any duplicate authors listed fromgit shortlog -ns
.Add any new authors to the
AUTHOR
file. Add any new entries to theTHANKS
file.Check the copyright years in
doc/conf.py
andLICENSE
Check the output of:
rst2html.py README.rst > ~/tmp/readme.html
because this will be the output used by PyPI
Check the dependencies listed in
pyproject.toml
and inrequirements.txt
and indoc/users/installation.rst
. They should at least match. Do they still hold? Make sure.github/workflows
is testing these minimum dependencies specifically.Check the examples. First download the example data by running something like:
# Install data packages. pip install https://nipy.org/data-packages/nipy-templates-0.3.tar.gz pip install https://nipy.org/data-packages/nipy-data-0.3.tar.gz
Then run the tests on the examples with:
# Move out of the source directory. cd .. # Make log file directory. mkdir ~/tmp/eg_logs ./nipy/tools/run_log_examples.py nipy/examples --log-path=~/tmp/eg_logs
in a virtualenv. Review the output in (e.g.)
~/tmp/eg_logs
. The output filesummary.txt
will have the pass file printout that therun_log_examples.py
script puts onto stdout while running.Check the documentation doctests pass:
virtualenv venv venv/bin/activate pip install -r doc-requirements.txt pip install -e . (cd docs && make clean-doctest)
Check the doc build:
virtualenv venv venv/bin/activate pip install -r doc-requirements.txt pip install -e . (cd docs && make html)
Build and test the Nipy wheels. See the wheel builder README for instructions. In summary, clone the wheel-building repo, edit the
.github/workflow
text files (if present) with the branch or commit for the release, commit and then push back up to github. This will trigger a wheel build and test on macOS, Linux and Windows. Check the build has passed on on the Github interface at https://travis-ci.org/MacPython/nipy-wheels. You’ll need commit privileges to thenipy-wheels
repo; ask Matthew Brett or on the mailing list if you do not have them.
Doing the release¶
The release should now be ready.
Edit
nipy/__init__.py
to set__version__
to e.g.0.6.0
.Edit
meson.build
to setversion
to match.Commit, then:
make source-release
For the wheel build / upload, follow the wheel builder README instructions again. Push. Check the build has passed on the Github interface. Now follow the instructions in the page above to download the built wheels to a local machine and upload to PyPI.
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:[pypi] username = __token__
Sign and upload the source release to PyPI using Twine:
gpg --detach-sign -a dist/nipy*.tar.gz twine upload dist/nipy*.tar.gz*
Tag the release with tag of form
0.6.0
. -s below makes a signed tag:git tag -s 'Second main release' 0.6.0
Now the version number is OK, push the docs to github pages with:
make upload-html
Start the new series.
Edit
nipy/__init__.py
and set version number to something of form:__version__ = "0.6.1.dev1"
where
0.6.0
was the previous release.Push tags:
git push --tags
Announce to the mailing lists.