How to create cherry-pick ๐Ÿ’ PRs into release branches

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.

    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. https://dgraph.io/docs 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

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.