Pacemaker Release Checklist

Repeat until final

 * If this is rc1:
 * Pull and merge master branch into 1.1 branch (can do for later rc's if really really sure it is desired)
 * Ensure that documentation (especially Clusters From Scratch, Pacemaker Explained, and Pacemaker Remote) and xml/*.rng are correct for all changes since the last release. You can also update the translation templates using, though we don't have any active translators at the moment.
 * Travis/buildbot only run the default basic sanity tests, so run the rest manually:
 * If practical, stress-test the current code with CTS, valgrind and coverity, and address any issues found.


 * Create a new commit(s) in 1.1 branch and push upstream, updating:
 * If this is rc1:
 * xml/Readme.md for pacemaker-to-schema version mapping
 * ChangeLog, by running  and then editing manually for user audience
 * shared library (libtool) versions for changes since last point release, by running, which will show all library diffs since the last release and ask whether the changes involve additions, incompatible additions, removals or fixes. The script assumes no library versions were changed since the last release, so verify its changes (which it displays at the end). Versions can be updated manually if later rc's break API (which they shouldn't). For details about library versioning, see Updating library version information.
 * version.m4, and pcmkversion in pacemaker.spec.in (to next version, without -rc suffix)
 * If this is a later rc:
 * ChangeLog, by adding the output of  to it and editing it appropriately
 * If this is the final release:
 * ChangeLog, by merging the rc entries into a single entry for the final release
 * possible improvement: also rerun the testsuite so as to generate (otherwise passing) results anew in order to make mere whitespace changes easier to track down  at least amongst final releases (note that pcs testsuite is whitespace sensitive)


 * If packages are desired for local testing, run  to get package version numbers that will match lower than the final release.


 * Make a github release:
 * Go to Pacemaker releases on Github and select
 * Tag version: new version (e.g. Pacemaker-1.1.14-rc1 or Pacemaker-1.1.14)
 * Target: 1.1
 * Release title: e.g. "Pacemaker 1.1.13 - Release Candidate 3" or "Pacemaker 1.1.13 - Final"
 * Describe this release: copy relevant part of ChangeLog
 * If this is an rc, check "This is a pre-release"


 * Publicize, e.g. see
 * http://blog.clusterlabs.org/blog/2014/release-candidate-1-dot-1-12-rc1/
 * http://oss.clusterlabs.org/pipermail/pacemaker/2014-May/021691.html
 * If this is rc1, announce request policy on developers@clusterlabs.org (features into master, fixes into 1.1)
 * To generate a list of contributors:


 * Pull 1.1 back into master branch and merge.


 * If this is an rc, wait for feedback, and address any reported issues. About 1-4 weeks between release candidates is good.

After final release

 * Run  at top level to regenerate most documentation on ClusterLabs.org website (doxygen, indexed source, Clusters From Scratch, Pacemaker Explained, etc.). Also run   to generate the ABI compatibility report.


 * Update on this wiki: ReleaseMatrix, ReleaseCalendar


 * Update in clusterlabs-www repo: html/js/versions.js


 * Announce request policy on developers@clusterlabs.org (all requests into master).


 * Close all pull requests open against 1.1 branch and invite to resubmit against master.


 * Release the new version to Fedora.


 * Ensure anitya picked up the new release.

Possible improvements

 * releases should not pretend to be full-fledged release (, etc.)


 * see also:
 * http://oss.clusterlabs.org/pipermail/users/2016-February/002372.html -- this should be solved by following the above   rule,  but still sub-optimal, hence the possible improvement to make    a first class citizen (and expose full truth  as a side-effect)