== 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 == * 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: ``` 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 [[http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html|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 [[https://github.com/ClusterLabs/libqb/issues/186|encoded as `defines` in a header file properly]]: ``` make ``` (watch for the 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.

== 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 [[http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html|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 [[https://github.com/ClusterLabs/libqb/issues/186|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.

== 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 == * 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: ``` 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 [[http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html|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 [[https://github.com/ClusterLabs/libqb/issues/186|encoded as `"defines`" in a header file properly]]: ``` make ``` (watchLook for thea 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.