Version 1 vs 2
Version 1 vs 2
Content Changes
Content Changes
== 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 ==
* 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.