Incorporate servicing release experience into release-manager playbooks#7656
Open
jeffhandley wants to merge 1 commit into
Open
Incorporate servicing release experience into release-manager playbooks#7656jeffhandley wants to merge 1 commit into
jeffhandley wants to merge 1 commit into
Conversation
…aybooks - Add startup stage-tree overview and per-stage progress rail to the agent's operating rules so each session opens with a process snapshot. - Require concrete next-step guidance after every stage so the user always knows the exact prompt or command needed to advance. - Add explicit run-location discipline: privileged and auth-sensitive commands use an editor-in-wait prompt for API keys and a terminal handoff block for AzDO/artifact/publish operations. - Add conditional Stage 7 (support-page) policy: skip for servicing releases that touch only existing packages; release-manager authors the dotnet/website PR when new packages are introduced; monthly releases review a partner-team PR. - Prefer the source main PR over the bot-authored backport PR in servicing release notes, with correct human author attribution. - Require a tag preflight check before creating a draft GitHub release. - Add Step 2 to the servicing preparation flow: survey the release branch and open PRs for existing backport activity; inform the user that the release-manager agent can efficiently cherry-pick from main as part of the servicing release process; pre-highlight identified source PRs as candidates in the selection table; classify already-released backports separately and surface them in a grounding table rather than omitting them. - Add release wrap-up rule: present a celebratory closing message with per-stage wall-clock timing and an estimate of active user-interaction time. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the release-manager agent playbooks to incorporate lessons learned from running an end-to-end servicing release, improving user guidance, clarifying conditional policies, and refining release-notes scope/attribution for backports.
Changes:
- Adds servicing-specific guidance for release-notes PR collection, including preferring source
mainPRs overrelease/*backport wrappers for attribution. - Makes Stage 7 (support-page follow-up) conditional based on monthly vs. servicing and whether new packages are introduced.
- Improves servicing preparation guidance by surveying existing backport activity and enhancing candidate/grounding tables.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| .github/agents/release-manager/write-release-notes/references/collect-prs.md | Adds servicing override to treat servicing-prep PR scope as canonical and prefer source main PRs for notes/attribution. |
| .github/agents/release-manager/write-release-notes/README.md | Documents backport attribution rule and adds tag preflight requirement before drafting GitHub releases. |
| .github/agents/release-manager/validate-release/references/stage-7-support-page.md | Refactors Stage 7 into decision-gated paths (monthly review vs. servicing skip vs. servicing author PR). |
| .github/agents/release-manager/validate-release/README.md | Updates Stage 7 description to reflect conditional policy and adjusts servicing guidance. |
| .github/agents/release-manager/publish-release/references/stage-4-publish-and-promote.md | Adds explicit “execution context” / terminal handoff expectations for auth-sensitive publish steps. |
| .github/agents/release-manager/prepare-release/references/stages-1-2-servicing-branch.md | Adds a backport-survey step and expands candidate selection/grounding tables for servicing prep. |
| .github/agents/release-manager.agent.md | Adds session-start stage-tree overview, progress rail guidance, terminal handoff guidance, and wrap-up timing summary requirements. |
Comments suppressed due to low confidence (2)
.github/agents/release-manager/validate-release/README.md:27
- The Stage 7 section heading says “Confirm the Support-Page Update”, but the referenced stage document is titled “Stage 7 - Support-Page Follow-up”. Aligning the heading text avoids confusion when users navigate between the README and the reference file.
## Stage 7 - Confirm the Support-Page Update
Stage 7 is conditional:
.github/agents/release-manager/prepare-release/references/stages-1-2-servicing-branch.md:190
- The notes section still says “aligned with Step 5”, but after renumbering the commit-application step is Step 6. This can send readers to the wrong step when ordering commits.
- Keep the `DO-NOT-SQUASH` label on the PR from creation through merge.
Comment on lines
+39
to
+42
| For each source `main` PR number identified, check whether it already shipped in a previous release: | ||
|
|
||
| - Run `git merge-base --is-ancestor <pr-merge-commit> <previous-tag>` to check ancestry. | ||
| - Or check whether the PR number appears in a prior release's release notes body. |
| - Stage 7 handles support-page follow-up based on release type and package novelty. | ||
|
|
||
| For servicing releases prepared directly on public `release/<major>.<minor>`, Stage 6 is often unnecessary because commits were backported from `main` into the release branch up front. In that case, run Stage 5 and Stage 7, and run Stage 6 only if the user explicitly asks for additional branch-flow follow-up. | ||
| For servicing releases prepared directly on public `release/<major>.<minor>`, Stage 6 is often unnecessary because commits were backported from `main` into the release branch up front. In that case, run Stage 5 and run Stage 6 only if the user explicitly asks for additional branch-flow follow-up. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
release-manageragent was used end-to-end for a servicing release, and a handful of practical improvements emerged from that experience.UX and guidance
Execution context
dotnet nuget push, BAR promotion) are handed off as explicit terminal blocks for the user to run outside the session.Stage 7 (support page) — conditional policy
dotnet/websitePR.Release notes — backport attribution
mainPR is preferred over the bot-authored backport PR, with the correct human author credited.Servicing preparation — backport survey
mainas part of the servicing process.mainPRs from open backport PRs are pre-highlighted in the candidate selection table.Release wrap-up