How to create cherry-pick 🍒 PRs into release branches

Dev
1

Official Dgraph releases are created from the following branches:

  • release/v20.03: Code for v20.03.0 and further patch releases v20.03.1, v20.03.2, and so on.
  • release/v20.07: Code for v20.07.0 and further patch releases v20.07.1, v20.07.2, and so on.
  • release/v1.2: Code for v1.2.0 and further patch releases v1.2.1, v1.2.2, and so on.
  • release/v1.1: Code for v1.1.0 and further patch releases v1.1.1, v1.1.2, and so on.

“Master” builds are built from the master branch:

  • master: The unreleased version of Dgraph. The master branch has all the latest changes and may include breaking changes slated for the next major release.

In general, branches named release/vX.Y. With calendar versioning, X is the year (“20” is the year 2020) and Y is the zero-padded month (“03” is March, “07” is July, “11” is November).

Once a release branch is cut, PRs must be made against master, get reviewed, and then get cherry-picked via PR into the release branch.

Cherry-picking to a release branch

The following example is about cherry-picking PR #5447 into a release branch release/v20.03. It has already been reviewed and merged into master.

  1. Get your commit SHA on master, e.g., 9f7efac4a11fab6051cc304dbe273d2d993aea1e:

    $ git log origin/master -1
commit 9f7efac4a11fab6051cc304dbe273d2d993aea1e
Author: Leyla Galatin <leyla@dgraph.io>
Date:   Fri May 15 15:40:35 2020 -0700

 Update CHANGELOG for 1.2.4 and 20.03.2. (#5447)

  2. Check out the release branch and create a new dev branch to cherry-pick your change:

    $ git checkout release/v20.03
# make sure you have the latest updates for the release branch
$ git pull --ff-only
# Create dev branch called <username>/<featureDescription>
$ git checkout -b danielmai/v20.03-changelog
# -x is optional. It appends the original SHA to your cherry-pick commit
$ git cherry-pick -x 9f7efac4a11fab6051cc304dbe273d2d993aea1e

  3. If you have merge conflicts, resolve them. If you need to make changes specific to this release branch, then you can do so now (e.g., to do a bug fix without breaking changes). Once it’s ready, you can push your branch and then make a PR:

    $ git push --set-upstream origin danielmai/v20.03-changelog

  4. When making the GitHub PR, choose the release branch as the base to merge into.

    image
    image1268Ă—270 35 KB

    Somewhere in your commit summary/description, you should include mention which GitHub issue or Jira ticket your PR is fixing. That way, the corresponding GitHub issue and Jira ticket gets a reference to your PR. And, it is very helpful to figure out which branch the change was checked into.

    ...

Fixes #123, DGRAPH-10

  5. Once the tests pass for your cherry-pick PR, you can merge it in the release branch. :tada:

FAQ

What if the release branch doesn’t exist yet?

Release branches are always cut off of master once the first beta is released. If the release branch doesn’t yet exist for a major release (e.g., release/v20.07), then you only need to merge your PR into master.

I have a change needed to fix a bug on the release. Where should the change go?

All changes always go into the master branch first. Once they’re in master, cherry-pick the change into the relevant release branches following the steps above.

I see a branch called release/vX.Y.Z (e.g., release/v20.03.1). Do I cherry-pick bug fixes to that too?

No.

The patch release branches are used to maintain the documentation for that patch release. Get started with Dgraph always points to the docs for the latest patch release. If you have doc changes that need to be reflected in the latest docs, then they need to be added to master and cherry-picked to the release branch for docs.

For v20.03.x releases and earlier, there’s a branch specific to the patch version where docs need to cherry-picked. e.g., release/20.03.6.

4 Likes
3

Step 1 is confusing, as this gets the last commit from master? What if that last commit is not your commit that you want to cherry-pick from 1 month ago?

Another way through GitHub UI is to look at Pull Request and scroll down to the moment that the PR was merged to master, this show a short SHA with a link to show the differences.

Alternatively, I look through git history, get the commit SHA (command line) from master.

4

Hey Daniel, I’ve been throw the pain of creating releases through cherry picking. The conclusion: wrong branching strategy. Take a look at the Feature workflow.