docs(release): update release process#11360
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the Radius release process documentation to clarify the cherry-pick workflow used across all release types (RC, final, and patch). It adds explicit step-by-step cherry-pick instructions, introduces a summary table showing what gets cherry-picked for each release type, and expands the guidance around single-commit discipline for the final release. Version placeholders are also normalized from lowercase vx.y.z to uppercase vX.Y.Z.
Changes:
- Added a new "Cherry-pick workflow" section summarizing the common pattern across all release types
- Added explicit shell commands for cherry-picking
versions.yamland optional commits onto the release branch during RC creation - Clarified the final release flow to require a single commit (version bump + release notes) and provided detailed cherry-pick steps with branch naming conventions
DariuszPorowski
force-pushed
the
dp/lengthy-alpaca-yellow
branch
from
5fb1a79 to
87836dc
Compare
| 1. Cherry-pick the `versions.yaml` commit - and optionally any additional commits that must be included in this RC - into the release branch. Create a new branch from the release branch (format: `release/x.y`) and open a PR targeting the release branch. | ||
|
|
||
| ```bash | ||
| git checkout release/0.<MINOR> |
There was a problem hiding this comment.
What step causes the release/0.<MINOR> to be created? Or does the operator create this branch? If a workflow is creating this branch then we should inform the operator that it is a side effect of an action they took.
My understanding (which could be wrong) is that merging the updated versions.yaml caused a workflow to run that creates the release branch, and that branch will already have the updated versions.yaml file in it. so no need to cherry pick this.
There was a problem hiding this comment.
The release/0. branch is created by workflows during the first release for a new channel. As per current documentation, the initial RC cut from main creates this branch. Subsequent RC cuts require a PR to main to update versions; other RC updates leave the release branch unchanged. Afterward, cherry-pick the RC from main to the existing release branch, adding patches if needed for the next RC.
|
|
||
| 1. After maintainer approval, merge the pull request to `main`. | ||
|
|
||
| 1. Cherry-pick the `versions.yaml` commit - and optionally any additional commits that must be included in this RC - into the release branch. Create a new branch from the release branch (format: `release/x.y`) and open a PR targeting the release branch. |
There was a problem hiding this comment.
If the release branch was just created from main, is there a need to cherry pick anything other than the versions.yaml file?
There was a problem hiding this comment.
At initial release, only the channel branch is created. For subsequent RCs, any fixes needed must be cherry-picked from main.
Signed-off-by: Dariusz Porowski <3431813+DariuszPorowski@users.noreply.github.com>
Signed-off-by: Dariusz Porowski <3431813+DariuszPorowski@users.noreply.github.com>
Signed-off-by: Dariusz Porowski <3431813+DariuszPorowski@users.noreply.github.com>
DariuszPorowski
force-pushed
the
dp/lengthy-alpaca-yellow
branch
from
87836dc to
c8f8874
Compare
Description
Clarification for release notes
Type of change
Contributor checklist
Please verify that the PR meets the following requirements, where applicable: