Release checklist

This release checklist is intended to ensure that Docker images and documentation build correctly without locking up the CI for 3+ hours. The critical piece is using [docs only] in the commit message of the release commit, which I recommend making the commit that updates the Changelog with the release date.

This checklist assumes release 1.0.0-rc9, which has a co-tag of 0.6.9, which we use to ensure that pip will upgrade. (By default -rcN releases are treated as pre-releases.)

• Check pins, release niworkflows (and try to urge a new pybids release) if necessary
• Full build on master with all features and final pins
• Verify http://readthedocs.org/projects/fmriprep/builds/ and check that the latest commit to master matches the latest successful build of RTD.
• Verify https://fmriprep.readthedocs.io/en/latest/ builds and looks reasonable
• Update changelog with current version and date; use commit message <version> Changelog [docs only]
• WAIT for Circle build completes (~20min) to check for any last-minute errors
• Make release on GitHub, incorporating all changes from the most recent changelog entry
• Co-tag on local repository and push to upstream
• Monitor CircleCI builds. If the Docker pull fails or image is rebuilding more layers than expected, cancel and rebuild.
• Verify PyPI releases (fmriprep and fmriprep-docker) and Docker tags
• Update dev version/changelog

Local tag

Again, we assume 1.0.0-rc9, with co-tag 0.6.9.

git fetch upstream
git checkout 1.0.0-rc9
git log -n 1  # Verify commit message
git tag 0.6.9
git push upstream 0.6.9

Update dev version/changelog

git fetch upstream
git checkout upstream/master

Update the dev version in fmriprep/info.py.

Add a new "Next release" entry to the CHANGES.rst:

sed -i '1s/^/Next release\n============\n\n\n/' CHANGES.rst

Commit and push:

git add CHANGES.rst fmriprep/info.py
git commit -m 'Update dev version, changelog [docs only]'
git push upstream HEAD:master

Notes on reducing CI usage

If you're on a branch off of current upstream/master (no merge necessary), then adding [skip ci] or [docs only] to the PR merge commit message will avoid re-running CI on exactly the same code on merge. If merging several PRs that don't touch the same code, using [skip ci] on all but the last will save time while not sacrificing testing assurance.