7.7. Releasing

The old repository
A tag jumps in
Plop
   —-after Matsuo Basho (1644-1694)

7.7.1. Releasing principles

  1. Cross-check CI green lights. Are all Travis builds green? Is nightly Jenkins build green?
  1. Cross-check Read The Docs documentation builds. Are docs building fine? Is this check done as part of the continuous integration? If not, add it.
  1. Cross-check demo site builds. Is demo site working?
  1. check-manifest Are all files included in the release? Is this check done as part of the continuous integration? If not, add it.
  1. Check author list. Are all committers listed in AUTHORS file? Use kwalitee check authors. Add newcomers. Is this check done as part of the continuous integration? If not, add it.
  1. Update I18N message catalogs.
  1. Update version number. Stick to semantic versioning.
  1. Generate release notes. Use kwalitee prepare release v1.1.0.. to generate release notes. Use empty commits with “AMENDS” to amend wrong past messages before releasing.
  1. Push a pre-release to testpypi. Try a test install from there.
  1. Tag it. Push it. Sign the tag with your GnuPG key. Push it to PyPI. Is the PyPI deployment done automatically as part of the continuous integration? If not, add it.
  1. Bump it. Don’t forget the issue the pull request with a post-release version bump. Use .devYYYYMMDD suffix.
  1. Add release notes on GitHub. Tweet it. Post it. Make publicity for production-ready releases. This is not automated yet.

7.7.2. Structured release notes

The release notes are prepared from the commit log messages that should include the following labels:

commit label release notes section
SECURITY Security fixes
INCOMPATIBLE Incompatible changes
NEW New features
BETTER Improved features
FIX Bug fixes
NOTE Notes
(AMENDS) (amending past messages)
(missing) (developers only)

For more, see kwalitee.