== Policies == * Pacemaker has a main branch, which gets all new development first, and release branches for major-minor series (such as 2.1 and 3.0). Only one or two release branches still receive development; older release branches do not. * When the highest-versioned major series starts a new release cycle, the main branch is pulled into its release branch for rc1. This means all main-branch development lands in the next rc1 of the highest-versioned major series. * If a change is desired in the highest-versioned major series during the release cycle (after rc1 is released but before final), or in an older major-version series, a PR backporting it to the desired release branch must be submitted separately. * During the release cycle, only bug-fix backports should be merged into a release branch. Near the end of the cycle, only regression fixes should be merged. == Testing == All of this should be done on the main branch just before rc1, addressing any issues found. Selected parts can be repeated for later release candidates when appropriate. * Run all **regression tests** (including cts-cli -t agents, cts-attrd, cts-fencing, cts-exec, and cts-exec -R; see `cts/README.md`). * Run a long **CTS lab** (see `cts/README.md`) against a several-node cluster using `CTSlab.py` or a wrapper such as `cts/cluster_test` or your own. * Perform **static analysis**. The devel directory has make targets for convenience (`cppcheck`, `clang`, and `coverity` or `coverity-corp`). * Verify **OCF agent meta-data** is valid (replacing $OCF_RNG_SCHEMA with the path to ra-api.rng from a local checkout of the OCF-spec source repository): ** `make RNG="$OCF_RNG_SCHEMA" -C agents/ocf validate` * Verify **formatted output** args using [[https://github.com/clumens/fosa/|fosa]]. * Locally generate all **documentation** that will be uploaded to the website, and proof changes since the last release. ** To see changes: `git diff Pacemaker-$LAST_RELEASE.. -- doc/sphinx` ** Ensure that significant new features are **documented** in //Pacemaker Explained// (with "(since <version>)" for new syntax or behavior). ** For a new major version, remove any "(since <version>)" for older versions no longer supported in a rolling upgrade. * Perform a **rolling upgrade** from any supported previous version. * Optionally, compare **scheduler timings** against the previous release to make sure there are no large unexplained regressions. From a checkout, run the first command below for the old and new builds, then run the second command 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. ** `PCMK_schema_directory=xml tools/crm_simulate --profile cts/scheduler/xml --repeat 1000 > ~/crm_simulate.$VERSION.out` ** `tools/pcmk_simtimes ~/crm_simulate.*.out -s 0.1 -p 5` * Optionally, check the current buildability in [[https://copr.fedorainfracloud.org/coprs/g/ClusterLabs/devel/builds/|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) == rc1 only == * **Pull main branch into release branch** ** If this is a new major or minor release, create the release branch, and ensure CI gets updated to check it. * Things that don't need to be done every release but are helpful every now and then: ** `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) ** **(Do not do this until we can raise the minimum automake dependency to 1.14)** `make -C maint gnulib-update` to update the code we bundle from gnulib * Make sure that the **[[/w/projects/pacemaker/pacemaker_feature_set/ | feature set]]** has been bumped appropriately for code changes in this release (the minor version if any new features require DC support including most schema changes, and the minor-minor version if any new features at all have been added including command-line tool arguments). * Make sure that **PCMK__API_VERSION** in `include/crm/common/output_internal.h` is equal to the highest version in the source file names in `xml/api`. * Update **translation files:** `make -C po update-po` * Update **xml/README.md** for pacemaker-to-schema version mapping, if needed ** To see schema changes since last release: `git log --no-merges Pacemaker-$LAST_VERSION.. xml` * Run **`maint/bumplibs`** 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 public API additions, incompatible public API additions/removals, or fixes. Verify the script's changes (which it displays at the end). ** Versions can be updated again for later release candidates if they break the public 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 [[http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html|Updating library version information]]. * Update **m4/version.m4** to new release version, without -rc suffix. ** When bumping the major or minor release number, `epub_identifier` in doc/sphinx/conf.py.in needs to be updated ** At some point, it might be worthwhile to include the -rc suffix for better differentiation of release candidates, but that will need a lot of testing to see how it affects RPMS, version comparisons, etc. === All releases === Repeat until final. All work is in the release branch. * Update the **Changelog:** ** **release candidates:** `make -C maint LAST_RELEASE=Pacemaker-$LAST_VERSION changelog` and then edit manually to make sense from a user perspective ** **final:** merge the rc entries into a single entry, then update summary with the output of `make -C maint LAST_RELEASE=Pacemaker-$LAST_FINAL_VERSION NEXT_RELEASE=Pacemaker-$NEW_VERSION summary` * Make a github release: ** Go to [[https://github.com/ClusterLabs/pacemaker/releases|Pacemaker releases on Github]] and select `Draft a new release` ** **Choose a tag:** Pacemaker-//X.Y.Z//-rc//N// 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 ** Can save as draft to preview if desired * If this release fixed any regressions, update the descriptions on GitHub of the releases that introduced the regressions * Publicize ** See for example https://lists.clusterlabs.org/pipermail/users/2019-October/026482.html (to generate a list of contributors, run `make -C maint LAST_RELEASE=Pacemaker-$PREVIOUS authors` or equivalently, `git log Pacemaker-$PREVIOUS..Pacemaker-$RC --format='%an'|sort -u`) ** If this is rc1, announce request policy on developers@clusterlabs.org (features into main, fixes into release branch), e.g. https://lists.clusterlabs.org/pipermail/developers/2019-October/002230.html * Pull release branch back into main 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 == * `export RSYNC_RSH="ssh -p $PORT"` appropriately for the ClusterLabs website host. * `git fetch upstream --tags` so the make targets can use the new release tag instead of commit ID. * Run `make -C doc www` to regenerate most documentation on ClusterLabs.org 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. * In the ClusterLabs project manager (this site): ** Update [[/w/projects/pacemaker/pacemaker_release_calendar/ | release calendar]] and [[/w/projects/pacemaker/pacemaker_feature_set/ | Pacemaker feature set]]. ** Update all relevant tasks from //Merged// status to //Released// (do [[https://projects.clusterlabs.org/maniphest/query/advanced/|Advanced Search]] for Merged status and release tag, then select all and bulk edit) ** Archive the release milestone(s) (go to milestone and select Manage then Archive) ** [[https://projects.clusterlabs.org/project/edit/?milestone=1|Create the next milestone(s)]] (which will be the release(s) after next)

== Policies == * Pacemaker's **main** branch gets all new development first. There are release branches for major-minor series (such as **2.1** and **3.0**). Only one or two release branches receive any changes; older release branches do not. The latest release series should be released first, then any supported older series. * When the latest series starts a new release cycle, the main branch is pulled into its release branch. This means all main-branch development lands in the latest series' next rc1. * If a change is desired in the latest series after an rc1 is released, or in an older series, a PR backporting it to the desired release branch must be submitted separately. * After rc1 is released, only bug-fix backports should be merged into the release branch (though exceptions can be made in unusual circumstances). After some later rc (typically around rc3), only regression fixes should be merged. * If this is the first release of a new major or minor release series, ensure the [[https://projects.clusterlabs.org/w/projects/pacemaker/release_series_prep/ | preparation]] is done first. == Testing == For the latest release series, this should be done just before rc1, addressing any issues found. Selected parts can be done for later release candidates or older release series as appropriate. Any fixes needed should be merged into the main branch. * Locally generate all **documentation** that will be uploaded to the website, and proof changes since the last release. ** To see changes: `git diff Pacemaker-$LAST_RELEASE.. -- doc/sphinx` ** Ensure that significant new features are **documented** in //Pacemaker Explained// (with "(since <version>)"). * Verify **OCF agent meta-data** is valid (replacing $OCF_RNG_SCHEMA with the path to ra-api.rng from a local checkout of the OCF-spec source repository): ** `make RNG="$OCF_RNG_SCHEMA" -C agents/ocf validate` * Verify **formatted output** args using [[https://github.com/clumens/fosa/|fosa]]. * Perform **static analysis**. The devel directory has make targets for convenience (`cppcheck`, `clang`, and `coverity` or `coverity-corp`). * Run all **regression tests** including `cts-cli -r agents`, `cts-attrd`, `cts-fencing`, `cts-exec`, and `cts-exec -R` (see `cts/README.md`). * Run a long **CTS lab** (see `cts/README.md`) against a several-node cluster using `cts-lab` or a wrapper (such as `cluster_test` or your own). * Do some **valgrind** testing on typical cluster behavior. `cts-lab` can be used for this, but ignore any test errors, just look at the valgrind results. * Test creating, starting, recovering, and stopping a **bundle** resource. For example, follow the [[https://projects.clusterlabs.org/w/projects/pacemaker/bundle_walk-through/ | bundle walk-through]], ban the bundle from one node to make sure the replica stops or moves appropriately, kill the containerized service in one replica (for example, `podman exec httpd-bundle-podman-$N killall -9 httpd`) to make sure it is recovered appropriately, kill pacemaker-remoted for a replica on its host to make sure it is recovered appropriately, then delete the bundle configuration. * Perform a **rolling upgrade** from any supported previous version. * Optionally, compare **scheduler timings** against the previous release to make sure there are no large unexplained regressions. From a checkout, run the first command below for the old and new builds, then run the second command 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. ** `PCMK_schema_directory=xml tools/crm_simulate --profile cts/scheduler/xml --repeat 1000 > ~/crm_simulate.$VERSION.out` ** `tools/pcmk_simtimes ~/crm_simulate.*.out -s 0.1 -p 5` == rc1 only == All changes should be made in the main branch for the latest release series, or the release branch for older release series. * Ensure the **[[/w/projects/pacemaker/pacemaker_feature_set/ | feature set]]** is correct. ** For the latest release series, make sure that it has been bumped appropriately for code changes in this release (the minor version if any new features require DC support including most schema changes, and the minor-minor version if any new features at all have been added including command-line tool arguments). ** For older release series, ensure it did //not// change in the release branch (and no features were backported that would require it). * Update **translation files**: `make -C po update-po` ** Once the PR is up, tag translators in a comment so they can submit updates before final release if desired (`git log po` will show translators) * Ensure the XML schema version is correct. ** For the latest release series, update **xml/README.md** in the main branch for the Pacemaker-to-schema version mapping if needed. To see schema changes since last release: `git diff Pacemaker-$LAST_VERSION.. xml` ** For older release series, ensure that the schema version did //not// change. * Run **`maint/bumplibs`** 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 public API additions, incompatible public API additions/removals, or fixes. Verify the script's changes (which it displays at the end). ** Incompatible changes should only be made at a major or minor series bump. ** Versions can be updated again for later release candidates if they break the public API (which should be avoided unless absolutely necessary) by running the script with `Pacemaker-$PREVIOUS_RC_TAG` as the argument. ** If this is for a new major or minor series, and an older series will continue to get releases, add another 20 to all libraries' "current interface" number (the first number in the `-version-info` argument), which will allow later releases in the older series to use the skipped range. ** If the bump is backward-incompatible (which should only happen for a new major or minor series), notify the CI maintainer so that various helpers can be rebuilt. ** For details about library versioning, see [[http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html|Updating library version information]]. * Update **m4/version.m4** to new release version, without -rc suffix. ** At some point, it might be worthwhile to include the -rc suffix for better differentiation of release candidates, but that will need a lot of testing to see how it affects RPMs, version comparisons, etc. * Merge a pull request for any changes. For the latest release series, pull main into the release branch. === All releases === Repeat until final. * Update the **Changelog** in the release branch: ** **release candidates:** `make -C maint LAST_RELEASE=Pacemaker-$LAST_VERSION changelog` and then edit manually to make sense from a user perspective (in particular, list all regression fixes at the top of each category with the release the regression was introduced in) ** **final:** merge the rc entries into a single entry, then update summary with the output of `make -C maint LAST_RELEASE=Pacemaker-$LAST_FINAL_VERSION NEXT_RELEASE=Pacemaker-$NEW_VERSION summary` ** Add the ChangeLog commit to the release branch using "Rebase and merge" (instead of "Create a merge commit"), and if it is for the latest series, forward-port it to the main branch * Make a github release: ** Go to [[https://github.com/ClusterLabs/pacemaker/releases|Pacemaker releases on Github]] and select `Draft a new release` ** **Choose a tag:** Pacemaker-//X.Y.Z//-rc//N// 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 ** Can save as draft to preview if desired * If this release fixed any regressions, update the descriptions on GitHub of the releases that introduced the regressions * Publicize ** Example: https://lists.clusterlabs.org/pipermail/users/2019-October/026482.html ** To generate a list of contributors: `make -C maint LAST_RELEASE=Pacemaker-$PREVIOUS authors` * 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 == * `git fetch upstream --tags` so the make targets can use the new release tag instead of commit ID. * Run `make -C doc www` to regenerate most documentation on ClusterLabs.org website (doxygen, indexed source, Clusters From Scratch, Pacemaker Explained, etc.). You must have an appropriate entry for sites.clusterlabs.org in `~/.ssh/config`. ** For some reason, this is only building //Clusters from Scratch// in all formats; the other books are singlehtml only. Until that can be figured out, do the `www` steps separately instead (you can build and upload the books from the doc/sphinx directory) * Run `make -C doc LAST_RELEASE=Pacemaker-$PREVIOUS_RELEASE TAG=Pacemaker-$NEW_RELEASE abi-www` to generate the ABI compatibility report. * In this wiki: ** Update [[/w/projects/pacemaker/pacemaker_release_calendar/ | release calendar]] and [[/w/projects/pacemaker/pacemaker_feature_set/ | Pacemaker feature set]]. ** Update all relevant tasks from //Merged// status to //Released// (do [[https://projects.clusterlabs.org/maniphest/query/advanced/|Advanced Search]] for Merged status and release tag, then select all and bulk edit) ** Archive the release milestone(s) (go to milestone and select **Manage** then **Archive**) ** If this is for the latest release series, [[https://projects.clusterlabs.org/project/edit/?milestone=1|Create the next milestone]] (which will be the release after next)

== Policies == * Pacemaker has a 's **main** branch, gets all new development first. which gets all new development first,There are release branches for major-minor series (such as **2.1** and **3.0**). andOnly one or two release branches for major-minor series (such as 2.1 and 3.0)receive any changes; older release branches do not. Only one or twoThe latest release branchseries still receive development;hould be released first, older release branches do notthen any supported older series. * When the highest-versioned majorlatest series starts a new release cycle, the main branch is pulled into its release branch for rc1. This means all main-branch development lands in the next rc1 of the highest-versioned major serieslatest series' next rc1. * If a change is desired in the highest-versioned majorlatest series during the release cycle (afterafter an rc1 is released but before final), or in an older major-version series, a PR backporting it to the desired release branch must be submitted separately. * During the release cycle,After rc1 is released, only bug-fix backports should be merged into the release branch (though exceptions can be made in unusual circumstances). only bug-fix backports should be merged into a release branch.After some later rc (typically around rc3), Near the end of the cycleonly regression fixes should be merged. * If this is the first release of a new major or minor release series, only regression fixes should be mergedensure the [[https://projects.clusterlabs.org/w/projects/pacemaker/release_series_prep/ | preparation]] is done first. == Testing == All ofFor the latest release series, this should be done on the main branch just before rc1, addressing any issues found. Selected parts can be done for later release candidates or older release series as appropriate. Selected parts can be repeated for later release candidates when appropriateAny fixes needed should be merged into the main branch. * Run all **regression tests** (including cts-cli -t agents, cts-attrd, cts-fencing, cts-exec, and cts-exec -R;* Locally generate all **documentation** that will be uploaded to the website, see `cts/README.md`)and proof changes since the last release. * Run a long **CTS lab** (see `cts/README.md`) against a several-node cluster using `CTSlab.py` or a wrapper such as `cts/cluster_test` or your own.* To see changes: `git diff Pacemaker-$LAST_RELEASE.. -- doc/sphinx` * Perform **static analysis**. The devel directory has make targets for convenience (`cppcheck`, `clang`, and `coverity` or `coverity-corp`* Ensure that significant new features are **documented** in //Pacemaker Explained// (with "(since <version>)"). * Verify **OCF agent meta-data** is valid (replacing $OCF_RNG_SCHEMA with the path to ra-api.rng from a local checkout of the OCF-spec source repository): ** `make RNG="$OCF_RNG_SCHEMA" -C agents/ocf validate` * Verify **formatted output** args using [[https://github.com/clumens/fosa/|fosa]]. * Locally generate all **documentation** that will be uploaded to the website* Perform **static analysis**. The devel directory has make targets for convenience (`cppcheck`, `clang`, and proof changes since the last release`coverity` or `coverity-corp`). ** To see changes: `git diff Pacemaker-$LAST_RELEASE..* Run all **regression tests** including `cts-cli -r agents`, `cts-attrd`, `cts-fencing`, `cts-exec`, -- doc/sphinx`and `cts-exec -R` (see `cts/README.md`). ** Ensure that significant new features are **documented** in //Pacemaker Explained// (with "(since <version>)" for new syntax or behavior Run a long **CTS lab** (see `cts/README.md`) against a several-node cluster using `cts-lab` or a wrapper (such as `cluster_test` or your own). ** For a new major version Do some **valgrind** testing on typical cluster behavior. `cts-lab` can be used for this, but ignore any test errors, just look at the valgrind results. * Test creating, starting, recovering, and stopping a **bundle** resource. For example, follow the [[https://projects.clusterlabs.org/w/projects/pacemaker/bundle_walk-through/ | bundle walk-through]], ban the bundle from one node to make sure the replica stops or moves appropriately, kill the containerized service in one replica (for example, `podman exec httpd-bundle-podman-$N killall -9 httpd`) to make sure it is recovered appropriately, kill pacemaker-remoted for a replica on its host to make sure it is recovered appropriately, remove any "(since <version>)" for older versions no longer supported in a rolling upgradethen delete the bundle configuration. * Perform a **rolling upgrade** from any supported previous version. * Optionally, compare **scheduler timings** against the previous release to make sure there are no large unexplained regressions. From a checkout, run the first command below for the old and new builds, then run the second command 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. ** `PCMK_schema_directory=xml tools/crm_simulate --profile cts/scheduler/xml --repeat 1000 > ~/crm_simulate.$VERSION.out` ** `tools/pcmk_simtimes ~/crm_simulate.*.out -s 0.1 -p 5` * Optionally, check the current buildability in [[https://copr.fedorainfracloud.org/coprs/g/ClusterLabs/devel/builds/|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) == rc1 only == * **Pull main branch into release branch** ** If this is a new major or minor release, create theAll changes should be made in the main branch for the latest release branchseries, and ensure CI gets updated to check it. * Things that don't need to be done every release but are helpful every now and then:or the release branch for older release series. * Ensure the **[[/w/projects/pacemaker/pacemaker_feature_set/ | feature set]]** is correct. ** `cts/cts-scheduler --update` (only if the tests already all pass!)** For the latest release series, to update whitespace usage in expected output (which is ignored by the regression testmake sure that it has been bumped appropriately for code changes in this release (the minor version if any new features require DC support including most schema changes, but can help manualand the minor-minor version if any new features at all have been added including comparisons)mand-line tool arguments). ** **(Do not do this until we can raise the minimum automake dependency to 1.14)** `make -C maint gnulib-update` to update the code we bundle from gnulib * Make sure that the **[[/w/projects/pacemaker/pacemaker_feature_set/ | feature set]]** has been bumped appropriately for code changes in this release (the minor version if any new features require DC support including most schema changFor older release series, and the minor-minor version if any new features at all have been added including command-line tool arguments). * Make sure that **PCMK__API_VERSION** in `include/crm/common/output_internal.h` is equal to the highest version in the source file names in `xml/api`ensure it did //not// change in the release branch (and no features were backported that would require it). * Update **translation files:** `make -C po update-po`**: `make -C po update-po` ** Once the PR is up, tag translators in a comment so they can submit updates before final release if desired (`git log po` will show translators) * Update **xml/README.md** for pacemaker-to-schema version mapping,Ensure the XML schema version is correct. ** For the latest release series, update **xml/README.md** in the main branch for the Pacemaker-to-schema version mapping if needed. To see schema changes since last release: `git diff Pacemaker-$LAST_VERSION.. if neededxml` ** To see schema changes since last** For older release: `git log --no-merges Pacemaker-$LAST_VERSION.. series, xml`ensure that the schema version did //not// change. * Run **`maint/bumplibs`** 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 public API additions, incompatible public API additions/removals, or fixes. Verify the script's changes (which it displays at the end). ** Incompatible changes should only be made at a major or minor series bump. ** Versions can be updated again for later release candidates if they break the public API (which should be avoided unless absolutely necessary) by running the script with `Pacemaker-$PREVIOUS_RC_TAG` as the argument. ** If this is for a new major or minor series, and an older series will continue to get releases, add another 20 to all libraries' "current interface" number (the first number in the `-version-info` argument), which will allow later releases in the older series to use the skipped range. ** If the bump is backward-incompatible (which should only happen for a new major or minor series), notify the CI maintainer so that various helpers can be rebuilt. ** For details about library versioning, see [[http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html|Updating library version information]]. * Update **m4/version.m4** to new release version, without -rc suffix. ** When bumping the major or minor release number** At some point, `epub_identifier` in doc/sphinx/conf.py.in needs to be updated ** At some pointit might be worthwhile to include the -rc suffix for better differentiation of release candidates, but that will need a lot of testing to see how it affects RPMs, version comparisons, it might be worthwhile to include the -rc suffix for better differentiation of release candidates, but that will need a lot of testing to see how it affects RPMS,etc. * Merge a pull request for any changes. version comparisonsFor the latest release series, etcpull main into the release branch. === All releases === Repeat until final. All work is in the release branch. * Update the **Changelog:**** in the release branch: ** **release candidates:** `make -C maint LAST_RELEASE=Pacemaker-$LAST_VERSION changelog` and then edit manually to make sense from a user perspective (in particular, list all regression fixes at the top of each category with the release the regression was introduced in) ** **final:** merge the rc entries into a single entry, then update summary with the output of `make -C maint LAST_RELEASE=Pacemaker-$LAST_FINAL_VERSION NEXT_RELEASE=Pacemaker-$NEW_VERSION summary` ** Add the ChangeLog commit to the release branch using "Rebase and merge" (instead of "Create a merge commit"), and if it is for the latest series, forward-port it to the main branch * Make a github release: ** Go to [[https://github.com/ClusterLabs/pacemaker/releases|Pacemaker releases on Github]] and select `Draft a new release` ** **Choose a tag:** Pacemaker-//X.Y.Z//-rc//N// 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 ** Can save as draft to preview if desired * If this release fixed any regressions, update the descriptions on GitHub of the releases that introduced the regressions * Publicize ** See for e** Example: https://lists.clusterlabs.org/pipermail/users/2019-October/026482.html (to generate a list of contributors, run `make -C maint LAST_RELEASE=Pacemaker-$PREVIOUS authors` or equivalently, `git log Pacemaker-$PREVIOUS..Pacemaker-$RC --format='%an'|sort -u`) ** If this is rc1, announce request policy on developers@clusterlabs.org (features into main, fixes into release branch), e.g. https://lists.clusterlabs.org/pipermail/developers/2019-October/002230.html * Pull release branch back into main branch and merge.To generate a list of contributors: `make -C maint LAST_RELEASE=Pacemaker-$PREVIOUS authors` * 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 == * `export RSYNC_RSH="ssh -p $PORT"` appropriately for the ClusterLabs website host. * `git fetch upstream --tags` so the make targets can use the new release tag instead of commit ID. * Run `make -C doc www` to regenerate most documentation on ClusterLabs.org website (doxygen, indexed source, Clusters From Scratch, Pacemaker Explained, etc.). You must have an appropriate entry for sites.clusterlabs.org in `~/.ssh/config`. ** For some reason, this is only building //Clusters from Scratch// in all formats; the other books are singlehtml only. Until that can be figured out, do the `www` steps separately instead (you can build and upload the books from the doc/sphinx directory) * Run `make -C doc LAST_RELEASE=Pacemaker-$PREVIOUS_RELEASE TAG=Pacemaker-$NEW_RELEASE abi-www` to generate the ABI compatibility report. * In the ClusterLabs project manager (this site):is wiki: ** Update [[/w/projects/pacemaker/pacemaker_release_calendar/ | release calendar]] and [[/w/projects/pacemaker/pacemaker_feature_set/ | Pacemaker feature set]]. ** Update all relevant tasks from //Merged// status to //Released// (do [[https://projects.clusterlabs.org/maniphest/query/advanced/|Advanced Search]] for Merged status and release tag, then select all and bulk edit) ** Archive the release milestone(s) (go to milestone and select **Manage** then **Archive**) ** If this is for the latest release series, [[https://projects.clusterlabs.org/project/edit/?milestone=1|Create the next milestone(s)]] (which will be the release(s) after next)