All fixes should be made on the develop branch first, and then backported if major/critical (to be include in one or more patch releases to facilitate quicker adoption).

Is it major/critical?

Fixes for cluster stability, availability, data loss or inconsistency, or loss of performance are some examples of major/critical issues that should be backported to all applicable active support branches.  If you are unsure, ask on the dev list.

How to backport

  1. In the GEODE Jira ticket, indicated the intended backport versions by adding a label in the format blocks-x.y.z
  2. Merge fix to develop (if it isn't already), then allow time for thorough testing (ideally at least a few days).
  3. Using git cherry-pick -x, work backward e.g. develop → support/1.15 → support/1.14  → support/1.12. 
    It's good practice to create a PR for each support branch, even if the cherry-pick goes smoothly.  Remember to ./gradle spotlessApply on each branch.  If you are a committer, merge your PR once you are satisfied.  Contributors can email the dev list if help is needed to merge backport PRs.
  4. Update Fix versions and Resolve the GEODE ticket (Release Manager will transition it from Resolved to Closed upon release).

Where to backport

In general any fix that is worth backporting should go to all affected versions still in support (see Release Schedule for a list).  Do not skip backporting to any in-between branches (exception: it's ok to skip 1.13).

FAQ

Q: Can fixes that are low-risk but not of “critical or major importance” be backported?
A: Users expect minimal changeset in patch releases, but you're welcome to make your case on the dev list.

Q: Should I remove the blocks-x.y.z label once the ticket is resolved and backported?
A: Preferably keep the blocker label.  It helps show that commits landing on support branches have followed the proper process.


  • No labels