This section contains notes about the process that is used to release Nitime.
Most of the release process is automated by the
release script in the
tools directory. This is just a handy reminder for the release manager.
Write release notes in
doc/whatsnew/for the current release. Use the notes that have hopefully accumulated in
doc/whatsnew/development. For writing release notes, this will cleanly show who contributed as author of commits (get the previous release name from the tag list with
git log –pretty=format:”* %aN” PREV_RELEASE... | sort | uniq
Uncomment the empty
version_extraassignment in the
version.pyfile, so that the complete version-string will not have the
Update the website with announcements and links to the updated files on github. Remember to put a short note both on the news page of the site, and the index
Make sure that the released version of the docs is live on the site.
build_release, which does all the file checking and building that the real release script will do. This will let you do test installations, check that the build procedure runs OK, etc.
Make the test installation from one of the release tarballs, make sure that:
- The installation is being done into a place in your PYTHONPATH, which will over-ride your development tree.
- The docs build in your test installation.
- The tests run and pass in your test installation.
releasescript, which makes the tar.gz, eggs and Win32 .exe installer. It posts them to the site and registers the release with PyPI.
Tag the current state of the repository:
git tag -a rel/x.y -m”Releasing version x.y” git push –tags origin master
Draft a short release announcement with highlights of the release (and send it off!).
Increment the version number in the
version.pyfile and comment the line with the additional
version_extra, so that you get back the
devtag on the version number.
Commit this as the beginning of the development of the next version.