Pacemaker Release Checklist

From ClusterLabs

Jump to: navigation, search

Repeat until final

  • Create new commit(s) in release branch (1.1 or 2.0) and push upstream, updating:
    • If this is rc1:
      • For 2.0 branch, pull and merge master branch (can do for later rc's if really really sure it is desired)
      • 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.
      • xml/ for pacemaker-to-schema version mapping
      • 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 again for later rc's if they break the API (which they shouldn't) by running Pacemaker-$PREVIOUS_RC_TAG. For details about library versioning, see Updating library version information.
      • version.m4, and pcmkversion in (to next version, without -rc suffix)
      • ChangeLog, by running make LAST_RELEASE=Pacemaker-$LAST_VERSION changelog and then editing manually for user audience
    • If this is a later rc:
      • ChangeLog, by running make; cat <(make rc-changes) <(git show HEAD:ChangeLog) > ChangeLog 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 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).
  • 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: /usr/share/pacemaker/tests/cts-regression -V exec pacemaker_remote fencing (2.0) or /usr/share/pacemaker/tests/ -V fencing pacemaker_remote (1.1)
  • Make a github release:
    • Go to Pacemaker releases on Github and select Draft a new release
    • Tag version: new version (e.g. Pacemaker-2.0.0-rc1 or Pacemaker-2.0.0)
    • Target: release branch
    • Release title: e.g. "Pacemaker 2.0.0 - Release Candidate 1" or "Pacemaker 2.0.0 - Final"
    • Describe this release: copy relevant part of ChangeLog
    • If this is an rc, check "This is a pre-release"
  • 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.)
  • 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
Personal tools