Pacemaker Release Checklist

Preparation for rc1

If packages are desired for local testing, run make WITH="--without doc --with pre_release" rpm to get package version numbers that will match lower than the final release (note: this is only useful before updating the pacemaker version number).

Create new commits in release branch (1.1 or 2.0) and push upstream:

  • 2.0 only:
    • Pull and merge master branch into 2.0 branch (can do for later rc's if really really sure it is desired, but normally changes should go the other direction once rc1 is released)
    • This could be a good time to run make -C gnulib-update
    • This could be a good time to run cts/cts-scheduler --update (only if the tests already all pass!), to update whitespace usage in expected output (which is ignored by the regression tests, but can help manual comparisons)
    • This could be a good time to compare scheduler timings against the previous release to make sure there are no large unexplained regressions. From a checkout, run tools/crm_simulate --profile cts/scheduler --repeat 1000 > ~/crm_simulate.$VERSION.out for the old and new builds, then run tools/pcmk_simtimes ~/crm_simulate.*.out -s 0.1 -p 5 to compare the two. Minimize variation however you can (use same host, don't do anything else while running it, maybe try to seed the disk read cache). There still is a good bit of variation from run to run so it is unclear at this point what is significant.
    • Ensure that all documentation is correct for all changes since the last release (including updating the copyright year and revision number, if applicable -- see Book_Info.xml and Revision_History.xml for each book).
    • Update xml/ for pacemaker-to-schema version mapping
  • Run script to update shared library (libtool) versions for changes since last point release, which will show all library diffs since the last release and ask whether the changes involve compatible additions, incompatible additions/removals, or fixes. Verify the script's changes (which it displays at the end). Versions can be updated again for later rc's if they break the API (which should be avoided unless absolutely necessary) by running the script with Pacemaker-$PREVIOUS_RC_TAG as the argument. For details about library versioning, see Updating library version information.
    • 2.0: maint/
    • 1.1: ./ Pacemaker-$LAST_VERSION
  • Update version.m4 to new release version, without -rc suffix.

Repeat until final

  • If practical, stress-test the current code with CTS, valgrind, and static analysis, and address any issues found.
    • Travis only runs the default regression tests, so run the rest manually:
      • 2.0: /usr/share/pacemaker/tests/cts-regression -V exec pacemaker_remote fencing
      • 1.1: /usr/share/pacemaker/tests/ -V fencing pacemaker_remote
    • There are three make targets for convenient static analysis: "make cppcheck", "make clang", and "make coverity" (or coverity-corp)
    • 2.0 only: run make -C maint testcc to verify that any public API changes are compatible with C++
  • 2.0: If this is the final release, it is a good idea to locally generate and proof all documentation that will be uploaded to the website.
  • Create new commit in release branch (1.1 or 2.0) and push upstream, to update Changelog:
    • rc1: run make LAST_RELEASE=Pacemaker-$LAST_VERSION changelog and then edit manually for user audience
    • later rc: run make; cat <(make LAST_RC=Pacemaker-$LAST_RC_VERSION rc-changes) <(git show HEAD:ChangeLog) > ChangeLog and edit appropriately
    • final release: merge the rc entries into a single entry (to update summary: make LAST_RELEASE=Pacemaker-$LAST_VERSION NEXT_RELEASE=Pacemaker-$NEXT_VERSION summary)
  • Make a github release:
    • Go to Pacemaker releases on Github and select Draft a new release
    • Tag version: Pacemaker-X.Y.Z-rcN or Pacemaker-X.Y.Z
    • Target: release branch
    • Release title: "Pacemaker X.Y.Z - Release Candidate N" or "Pacemaker X.Y.Z - Final"
    • Describe this release: copy relevant part of ChangeLog
    • This is a pre-release: check if this is an rc
  • 2.0: Pull release branch 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

  • Set and export the RSYNC_RSH environment variable appropriately for the ClusterLabs website host (e.g. "ssh -p <#>")
  • Run make -C doc www to regenerate most documentation on website (doxygen, indexed source, Clusters From Scratch, Pacemaker Explained, etc.).
  • Run make -C doc LAST_RELEASE=Pacemaker-$PREVIOUS_RELEASE TAG=Pacemaker-$NEW_RELEASE abi-www to generate the ABI compatibility report.
    • Recent versions of abi-compliance-checker (including 2.2) force g++ when checking headers. Pacemaker 2.0.0+ should be OK with this, but earlier versions will need to use an older abi-compliance-checker (1.99.20 is known to work).
  • Announce request policy on (all requests into master).
  • Edit any pull requests open against the release branch to submit against master.
  • Release the new version to Fedora.
  • Ensure anitya picked up the new release.

Possible improvements

  • rcX releases should not pretend to be full-fledged release (version.m4, etc.)
  • before any tagged/point release (at latest), check the current buildability in COPR (default sort starts with the newest builds, optionally use pacemaker in the filter box, check at least Git branch field on the details page, optionally also git commit encoded in the R part of package identifier)