Libqb Release Checklist

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
make distclean rm -rf autom4te.cache aclocal.m4 m4 configure ,/autogen.sh ./configure make -f build-aux/release.mk version=$NEW_RELEASE_VERSION release=yes [gpgsignkey=$KEY] make (watch for the line like warning: "1.0.0.17-43ef" parsed as: "1" "." "0" "." "0" ".17-43ef") git push --follow-tags origin ./build-aux/generate-docs
 * This should be done from a system with a reasonably recent automake and autoconf (e.g. RHEL7).
 * 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:
 * Edit the  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):
 * Ensure that version is encoded as s in a header file properly:
 * Ensure upstream has the new commit and tag (replace origin if upstream is configured differently in for your checkout):
 * 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).
 * 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, but that's a legacy location that should probably be removed eventually.