You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/Cherry-picks-to-a-release-channel.md
+37-57Lines changed: 37 additions & 57 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,7 @@
1
-
> [!IMPORTANT]
2
-
> This page was copied from https://github.com/dart-lang/sdk/wiki and needs review.
3
-
> Please [contribute](../CONTRIBUTING.md) changes to bring it up-to-date -
4
-
> removing this header - or send a CL to delete the file.
5
-
6
-
---
1
+
# Cherry-picks to a Release Channel
7
2
8
3
Cherry-picking is the process of selecting and merging an existing bug fix from our main development branch into a release branch (e.g. from `main` to `beta` or `stable`) for inclusion into the next hotfix release.
9
4
10
-
With the Dart and Flutter joint release process, we're using a combined [Dart & Flutter Cherrypick Review and Approval Process](https://github.com/flutter/flutter/wiki/Flutter-Cherrypick-Process). This document is a supplement to the main process and describes the process and flow within the Dart team.
11
-
12
5
**Note**: This process applies to bugs and regressions. Feature work is not considered for cherry picking and will need to wait for the next release.
13
6
14
7
## Notice a cherry-pick is required
@@ -34,31 +27,46 @@ Update the commit message accordingly:
34
27
1. Add a `[beta]` or `[stable]` gerrit hashtag at the start of the first line.
35
28
2. Rename the `Reviewed-on` field to `Cherry-pick` to link to the original
36
29
changelist being cherry-picked.\
37
-
3. Add a temporary `Cherry-pick-request` field to be filled in later.
38
-
4. Remove the conflicting fields `Change-id`, `Commit-queue`, `Reviewed-by` that
30
+
3. Remove the conflicting fields `Change-id`, `Commit-queue`, `Reviewed-by` that
39
31
are not true of the new changelist.
32
+
4. Fill out the changelist description with the following information:
33
+
1. Issue description: (Brief description of the issue. What is the issue?
34
+
What platforms are the problems occurring on?)
35
+
2. What is the fix: (Brief description of the fix)
36
+
3. Why cherry-pick: (Describe the reasons, impacted users and functional
37
+
issues to explain why this should be cherry-picked.)
38
+
4. Risk: (Describe the risks associated with this cherry-pick.)
39
+
5. Issue link(s): (Add links to the original issues fixed by this
40
+
cherry-pick.)
40
41
41
42
E.g.:
42
43
43
44
```
44
45
[stable] Fix foo crash.
45
46
46
-
Avoid foo doing bar instead.
47
+
Issue description: When attempting to use foo under certain conditions, users are unable to
48
+
compile.
49
+
What is the fix: foo is now evaluated at runtime.
50
+
Why cherry-pick: Users of foo are no longer able to compile to bar.
51
+
Risk: Low, this fix has landed on the main channel and is tested on the same infrastructure.
Stable cherry-picks [must have CHANGELOG.md entries](Gerrit-Submit-Requirements#changelog) explaining the changes. The release engineers don't have your full context and rely on this information.
59
+
Stable cherry-picks [must have CHANGELOG.md entries](Gerrit-Submit-Requirements#changelog)
60
+
explaining the changes. The release engineers don't have your full context and rely on this
61
+
information.
58
62
59
63
Beta releases don't have changelog entries.
60
64
61
-
If the `CHANGELOG.md` does not already have a section for the next stable hotfix, add such a section and increase the patch number (e.g. `3.0.4` -> `3.0.5`) without a date. If a section has a release date, it has already been released and should not be modified. The date will be added when the stable release is authored and it is decided when the release will be published.
65
+
If the `CHANGELOG.md` does not already have a section for the next stable
66
+
hotfix, add such a section and increase the patch number (e.g. `3.0.4` ->
67
+
`3.0.5`) without a date. If a section has a release date, it has already been
68
+
released and should not be modified. The date will be added when the stable
69
+
release is authored and it is decided when the release will be published.
62
70
63
71
```markdown
64
72
## 3.0.5
@@ -67,18 +75,19 @@ This is a patch release that:
67
75
68
76
- Fixes all bugs in the Dart SDK (issue [#123456])
Link to your cherry-pick request as subsequently filed below. You can upload the changelist again with the final link once the GitHub issue has been filed. The cherry-pick request on GitHub is often more useful for users than the original bug, since it explains the rationale concisely and links to the underlying bug for more information.
80
-
81
-
If the cherry-pick is infrastructure only and is invisible to users, the `Changelog-Exempt: ...` footer exempts the change from the changelog requirement.
88
+
If the cherry-pick is infrastructure only and is invisible to users, the
89
+
`Changelog-Exempt: ...` footer exempts the change from the changelog
90
+
requirement.
82
91
83
92
## Uploading the cherry-pick changelist
84
93
@@ -91,43 +100,14 @@ git cl upload
91
100
Trigger a commit queue dry run and add any appropriate try builders to confirm
92
101
the fix is correct.
93
102
94
-
## Request cherry-pick approval
95
-
96
-
Request approval for releasing the fix to beta/stable using
97
-
this [cherry-pick to beta/stable request template][cherry-pick-template]:
98
-
99
-
* Brief description of the problem.
100
-
* The reason for cherry pick, user impact, and a brief risk assessment
101
-
(low/medium/high).
102
-
* Link to the changelist.
103
-
* The `cherry-pick-review` label.
104
-
105
-
Edit the changelist's commit message with a link to the cherry-pick request:
0 commit comments