Update release-checklist.md#13754
Conversation
Phase 1.3 of the release checklist previously only described inserting the new release branch into .config/git-merge-flow-config.jsonc. It said nothing about removing retired predecessor VS preview branches, so each release relied on someone noticing the stale entries (e.g. PR dotnet#13750 had to retire vs18.4 and vs18.5 manually after vs18.6 opened). Expand step 1.3 into 1.3a (insert new branch), 1.3b (retire unsupported predecessor preview branches), and 1.3c (sanity-check the resulting chain) so the cleanup happens as part of the same PR that adds the new branch. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR updates the release checklist to make merge-flow branch retirement an explicit part of adding a new release branch, helping keep automated forward-merge PRs aligned with supported VS branches.
Changes:
- Splits release checklist step 1.3 into explicit substeps.
- Adds guidance to retire unsupported predecessor preview branches from
.config/git-merge-flow-config.jsonc. - Adds a sanity-check step for validating the resulting merge chain.
Remove the made-up criterion describing exactly when a branch is retired (content merged forward + past LTSC/STS / no future patches). That heuristic was not based on any documented policy and risks being wrong. Leave 1.3b as a prompt to retire predecessor branches that will no longer be supported, with the example PR for context. Reasoning for how to identify a retired branch will be added separately. Also drop 1.3c (chain well-formedness check) — the new sub-step doesn't need that scaffolding. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Documentation review — no issues found.
The decomposition of step 1.3 into sub-steps (1.3a–1.3c) is well-structured and consistent with the existing pattern used for step 1.2 (1.2a–1.2e). The new branch-retirement guidance in 1.3b is detailed, actionable, and correctly describes the mechanics of the merge-flow config. The verification step in 1.3c adds a useful safety gate. The cross-reference to PR #13750 as a concrete example is helpful for future release operators.
Formatting and markdown nesting are correct.
Note
🔒 Integrity filter blocked 1 item
The following item were blocked because they don't meet the GitHub integrity level.
- #13754
pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
To allow these resources, lower min-integrity in your GitHub frontmatter:
tools:
github:
min-integrity: approved # merged | approved | unapproved | noneGenerated by Expert Code Review (on open) for issue #13754 · ● 1.5M
For SDK releases, refer to the lifecycle table in the SDK/MSBuild/VS versioning doc. For VS releases, the retired branch is always the immediate predecessor of the one being released. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The release checklist already covers BootstrapSdkVersion (the SDK that hosts bootstrap test runs) but not the tools.dotnet pin in global.json (the SDK that builds MSBuild itself, surfaced as DotNetCliVersion in eng/Versions.props and required to match per the comment there). Add 5.4b so the build-side SDK is refreshed on the same monthly cadence as new SDK releases. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
OvesN
changed the title
Context
Phase 1.3 of the release checklist previously only described inserting the new release branch into .config/git-merge-flow-config.jsonc. It said nothing about removing retired predecessor VS preview branches.
Changes Made
Expand step 1.3 into 1.3a (insert new branch), 1.3b (retire unsupported predecessor preview branches), and 1.3c (sanity-check the resulting chain) so the cleanup happens as part of the same PR that adds the new branch.