Flutter Cherry-pick Process

Goal

With branching and branch testability being supported for Flutter & Dart releases, cherry-picking fixes is the preferred method to address issues for released software (beta and stable channels). Stability of the release will be the overarching goal, so only highly impactful and critical cherry-picks will be allowed across Dart and Flutter. This document outlines the process for requesting and approval of cherry-picks.

Note: This process applies to regressions from the previous release or serious bugs otherwise introduced by the current release. Feature work is not considered for cherry-picking and will need to wait for the next release.

Automatically Create a Cherry-pick Request

[NOTE] If you are trying to open a cherry-pick before that release has shipped (e.g., you would like to CP into 3.21 beta but the current beta is 3.20) then you will need to follow the manual cherry-pick instructions below.

Add the cp: beta or cp: stable label to the pull request on flutter/flutter master. (you can find beta and stable candidate branch info by following the respective links)
Wait about 30 seconds.
If automatic cherry-pick succeeds (no merge conflict), a new pull requested will be created and you will receive an email. Edit the cherry-pick details in the PR description of the generated pull request, and a release engineer will follow up on the request.
If automatic cherry-pick fails, a comment will be left on the original PR. In this case you will need to follow instructions in the manual cherry-pick section below to manually create a cherry-pick PR.

If for some reason, an automated cherry-pick can not be applied, please follow the manual cherry-pick instructions.

Manually Create a Cherry-pick Request

If the automated cherry-pick process fails, you will have to create the cherry-pick request manually:

Create a cherry-pick pull request to the intended branch.

How to find the intended branch: You can find the current beta and stable candidate branches by following the respective links. For a pre-release branch, you will need to locate the correct candidate branch yourself. It should follow the pattern flutter-X.XX-candidate.X where X.XX is the release you are targeting.

Edit the title of the cherry-pick request to start with either [beta] or [stable].
Fill out the PR description with the following fields:

Impacted Users (Approximately who will hit this issue, ex. all Flutter devs, Windows developers, all end-customers, apps using X framework feature).
Impact Description (What is the impact? ex. visual jank on Samsung phones, app crash, cannot ship an iOS app. Does it impact development? ex. flutter doctor crashes when Android Studio is installed. Or shipping a production app? ex. the app crashes on launch).
Workaround (Is there a workaround for this issue?)
Risk (What is the risk level of this cherry-pick?)
Test Coverage (Are you confident that your fix is well-tested by automated tests?)
Validation Steps (What are the steps to validate that this fix works?)

Frequently asked questions

Who can request a cherry-pick?

Anyone can request a cherry-pick.

When do I request a cherry-pick?

Whenever you have identified a commit on the main/master that fixes an issue that is present on the beta or stable branch.
Whenever you need to update a pub dependency that fixes an issue that is present on the beta or stable branch (see Updating dependencies

Who reviews and approves cherry-pick requests?

The release engineering team will assign a cherry-pick reviewer who is an expert in the area of the code that your cherry-pick may affect.

Why was my cherry-pick rejected

While we attempt to address every cherry-pick requests, there are various reasons a cherry-pick request may not be accepted to include, but not limited to:

Not filling out the pull request info appropriately.
Attempting to cherry-pick something other than a fix.
etc.

Lifecycle of a cherry-pick

The cherry-pick requester opens a cherry-pick pull request to the beta or stable candidate branch (follow the respective link to find the branch name)
The release engineering team is notified that a cherry-pick request is in queue and assigns an appropriate reviewer who is an expert in the area who will review the cherry-pick issue and associated cherry-pick pull request.
The release engineering team applies the merge-to-beta or merge-to-stable label.
The cherry-pick request then enters one of the following states.
1. Approved: The reviewer has approved the cherry-pick and cherry-pick pull request. The release engineering team will merge the cherry-pick pull request and apply the cp: merged label to the cherry-pick issue.
2. Denied: The reviewer will comment on the cherry-pick issue why the cherry-pick is denied. The release engineering team will close the cherry-pick issue and associated cherry-pick pull request.
The cherry-pick is picked up in the next release period.
Once the cherry-pick has been added to a release, the release engineering team will close the cherry-pick issue.

This is my first cherry-pick, how do I do it?

This is the perfect opportunity for you to learn and add cherry-picking to your toolbox. A typical cherry-pick request follows a process similar to the below.

Note: Commands that are wrapped with < > are variables that apply to your specific situation.

git checkout <master/main>
git fetch
git pull // ensure all changes from master/main have been pulled
git checkout <candidate branch you want to cherry-pick to>
git checkout -b <your local branch name for cherry-picking>
git cherry-pick <your commit hash>
git push --set-upstream origin <your branch name>

What happens if my cherry-pick PR has merge conflicts?

In the case that your cherry-pick commit has a merge conflict, it is up to you to resolve it. If you can not resolve it, reach out to the original PR author who may be able to help resolve the conflict.

What if the issue is on a previous stable?

If you discovered an issue on a X version that is no longer on the stable channel, we can still hotfix it in. For stables, we are more likely to do this as that is what most Flutter developers use.

Generally, if the stable is relatively fresh, such as we recently shipped the new stable and a large chunk of developers have not migrated, we would prioritize backporting a fix.

When should I prioritize fixes to beta instead of stable?

Generally, we ship every third beta to stable, and prioritize fixes to those branches as those are soon to be stable. We have no official comms planned around this yet, but will encourage developers on Discord to try out this beta.

In the last few weeks of a stable, we may opt to only release hotfixes to the beta instead of stable. At end of 2023, we're planning to have more automation around releases, which will allow us to ship hotfixes to both channels easily, and this will be less of a concern.