LibQB Release Checklist

Updated 346 Days AgoPublic

Actions

Pre-release testing

Run the internal test suite on all supported operating systems.

BSD-based systems must use gmake, e.g.:

./autogen.sh
MAKE=gmake ./configure --prefix=/usr/local
gmake all check

Release process

• Ensure you have a completely clean and up-to-date checkout, either by making a new one or by pulling from upstream master and running:

make maintainer-clean
./autogen.sh
./configure

• Edit the -version-info version in lib/Makefile.am appropriately to the release. For details on library versioning, see Updating library version information.

• Commit that change, but do not push yet.

• Build and GPG-sign the tarballs, and tag the release (either pass in a GPG key or edit the default in the file):

make -f build-aux/release.mk version=$NEW_RELEASE_VERSION release=yes [gpgsignkey=$KEY]

• Ensure that version is encoded as "defines" in a header file properly:

make

Look for a line like: warning: "1.0.0.17-43ef" parsed as: "1" "." "0" "." "0" ".17-43ef"

• Ensure upstream has the new commit and tag (replace origin if upstream is configured differently in for your checkout):

git push --follow-tags origin

• Update the generated documentation:
  • Checkout the gh-pages branch
  • Pull in changes from master branch (merge and commit if necessary).
  • From the top level of the checkout, run the following to generate online documentation (ABI compatibility, API documentation and changelog).

./build-aux/generate-docs

• • Edit index.html to link to the new release
  • Push the local gh-pages branch upstream, and it will appear at http://clusterlabs.github.io/libqb/
• We used to upload the release to https://fedorahosted.org/releases/q/u/quarterback/, using scp libqb-$NEW_RELEASE_VERSION.* fedorahosted.org:quarterback, but that's a legacy location that should probably be removed eventually.