Pacemaker Release Checklist

From ClusterLabs
Jump to: navigation, search

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)
  • 2.0 only: This could be a good time to run make -C gnulib-update
  • Ensure that all documentation is correct for all changes since the last release (including updating the copyright year and revision number, if applicable). This also could be a good time to update the translation templates using make -C doc pot, though we don't have any active translators at the moment.
  • 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, and pcmkversion in (to next version, without -rc suffix)

Repeat until final

  • If practical, stress-test the current code with CTS, valgrind and coverity, 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
    • 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

  • Run make www at top level to regenerate most documentation on website (doxygen, indexed source, Clusters From Scratch, Pacemaker Explained, etc.).
  • Run make LAST_RELEASE=Pacemaker-$PREVIOUS_RELEASE TAG=Pacemaker-$NEW_RELEASE abi-www at the top level 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.)
  • Final release: rerun the test suite 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)
  • 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)
  • up for discussion: dealing with (so far only documentation) translations could be partitioned into cyclic stages synchronized with the release cycle, say: string freeze on the first release candidate (at which point pot files would be refreshed in the git repo), followed with a period of accepting the translations on 1.1 branch until the final release, which would lift the string freeze again
    • the reason behind this would be to eleminate the unnecessary burden connected with errorprone efforts to keep pot files up-to-date any time, for instance, see PR#1295 -- as opposed to the systemic, holistic approach