docs(docs/about/contributing): document cutting a release branch#26950
docs(docs/about/contributing): document cutting a release branch#26950f0ssel wants to merge 3 commits into
Conversation
Docs preview📖 View docs preview for |
mtojek
left a comment
There was a problem hiding this comment.
I'm catching up with the status quo, so don't irritate if my questions/comments are ridiculous.
| step, continuing the RC numbering sequence. | ||
|
|
||
| > The automated `create-release-branch` workflow (Tag and Release) is still | ||
| > experimental. Cutting the branch by hand is the current default; see |
There was a problem hiding this comment.
WDYM by experimental? Should we use it or not yet?
| </details> | ||
|
|
||
| The release branch now exists on the remote and tracks | ||
| `origin/release/<version>`. |
There was a problem hiding this comment.
At this point, we don't process/prepare any release notes... yet, correct?
| If you want to create a new branch to retain commits you create, you may | ||
| do so (now or later) by using -c with the switch command. Example: | ||
|
|
||
| git switch -c <new-branch-name> | ||
|
|
||
| Or undo this operation with: | ||
|
|
||
| git switch - |
There was a problem hiding this comment.
nit: perhaps trim the output, so it won't confuse operators
| branch and set the remote as its upstream: | ||
|
|
||
| ```shell | ||
| git push --set-upstream origin release/<version> |
There was a problem hiding this comment.
- In a few words:
git checkout <main or commit SHA>
git checkout -b "release/<next release number>"
git push origin "release/<next release number>"
correct?
- If yes, then I don't see how that matches the Release.yaml workflow:
Use workflow from: <main or commit SHA>
Release channel: ?
Release notes for the publishing the release. This is required to create a release: ?
EDIT:
Ok, I see that there is another workflow file Tag and Release. Could you link it in this document, or is it a temporary name?
- Yesterday you just created the branch
release/2.35, and no RC tagged?
| Replace the placeholders in the commands below: | ||
|
|
||
| - `<commit-sha>`: the full commit SHA you want to release from. | ||
| - `release/<version>`: the release branch name, following the `release/X.Y` |
There was a problem hiding this comment.
QQ regarding the automated method via create-release-branch:
Does the workflow automatically figure out the correct version? I mean, it should be straightforward for the next release v2.35, but how does it work if I want to release a patch v2.34.12? Can I specify that with the workflow?
Adds a "Cutting a release branch" subsection to the Releases docs in
docs/about/contributing/CONTRIBUTING.md, documenting the current default way to start a new release: cut arelease/X.Ybranch by hand from the target commit (check out the commit, create the branch, and push it with an upstream). Each step includes example git output.It also marks the automated
create-release-branch(Tag and Release) workflow as experimental in the Workflow section, since manual branch cutting is the current default.Decision log
## Releasessection ofdocs/about/contributing/CONTRIBUTING.md(maintainer release process), not the user-facingdocs/install/releases/.create-release-branchworkflow (.github/workflows/tag-and-release.yaml) is still experimental, so the Workflow section now carries an experimental note that points to the manual steps.<details>blocks for scannability. The commit SHA and branch name are placeholders (<commit-sha>,<short-sha>,release/<version>).markdownlint-cli2and Vale both report 0 issues on the file.