CCCaster Cherrypick Process - lurkydismal/CCCaster GitHub Wiki

CCCaster Cherry-pick Process

Goal

With branching and branch testability being supported for CCCaster & 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 high impactful and critical cherrypicks will be allowed across Dart and CCCaster. This document outlines the process for requesting and approval of cherrypicks.

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.

Frequently asked questions

How do I request a cherry-pick?

To request a cherry-pick, utilize the issue template.

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.

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.

Lifecycle of a cherry-pick

  1. The cherry-pick requester opens a cherry-pick pull request to the beta or stable branch. A cherry-pick issue is filled out completely and created utilizing the cherry-pick template in the flutter/flutter repository.
  2. 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.
  3. The release engineering team applies the merge-to-beta or merge-to-stable label.
  4. 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.
  5. The cherry-pick is picked up in the next release period.
  6. 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.

  1. git checkout <master/main>
  2. git fetch
  3. git pull // ensure all changes from master/main have been pulled
  4. git checkout <candidate branch you want to cherry-pick to>
  5. git checkout -b <your local branch name for cherry-picking>
  6. git cherry-pick <your commit hash>
  7. 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.