Skip to content

Cherry picks to a release channel

Kevin Chisholm edited this page Apr 15, 2022 · 42 revisions

With the Dart and Flutter joint release process, we're using a combined Dart & Flutter Cherrypick Review and Approval Process. This document is a supplement to the main process and describes the process and flow within the Dart team.

Note: This process applies to bugs and regressions. Feature work is not considered for cherrypicking and will need to wait for the next release.

The cherry pick process

  1. A issue is opened, triaged by subteams, ...
  2. Issue fixed and verified in master
  3. Engineer checks the CL merges cleanly to the destination branch
  4. Engineer ensures that all tests are passing
  5. Engineer or TL open a new issue (please use the merge request template)
  6. TPM brings the issue to the next scrum meeting for approval

The new issue should contain the following information:

  • Brief description of the problem
  • The reason for cherry pick, user impact, and a brief risk assessment (low/medium/high)
  • The cherry-pick-review label

If approved, the scrum team will apply the proper label(s) - cherry-pick-approved, and one or both of merge-to-beta and merge-to-stable.

Then:

  1. Dart EngProd team members will perform the merge and ensure it landed.
  2. Dart EngProd team members will open issues to notify Flutter team to cherrypick the changes (Sample: https://github.com/flutter/flutter/issues/55575)

Getting your changes ready for cherry pick

Step 1

Resolve the issue and land it as a CL against the master branch. Validate that the issue was resolved in master.

Step 2

Check that your CL merges cleanly to the stable branch (for beta, replace stable with beta):

$ git fetch
$ git new-branch --upstream origin/stable cherry
$ git cherry-pick #HASH_FROM_MASTER_THAT_NEEDS_CHERRY_PICKING

Step 3

Then, build and run the tests, and ensure that all tests are passing.

If it does not merge cleanly please supply a patch by fixing merge conflicts locally and uploading a changelist (CL) by doing git cl upload, and link to the review in the merge request. The CL needs to be reviewed (Code-Review: +1) like any other CL but will be landed by a release engineer. Do not land it yourself!

Merge to beta/stable template

Please use this merge to beta/stable request template template.

Clone this wiki locally