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
{{ message }}
Repository navigation
ci(release): reuse the promoted pre-release's release notes preview for stable releases #4753
As the release captain, I want the stable release notes to be the notes the community already reviewed, so what I present at the Tuesday community meeting is what ships.
Problem Statement
Every Pre-release run writes an advisory release notes preview (Preview Release Notes, release-notes artifact) with .github/workflows/release-notes.yml. When Release promotes that pre-release, release-publish.yml runs Write Release Notes again and uses the new output as the GitHub Release body.
The generator is a Claude agent with no fixed seed, so the second run can word, group, and order items differently from the preview, and can drop or add upgrade notes. The stable release covers exactly the same PRs as the promoted pre-release (same comparison base, same commit), so regenerating adds variance without adding information. For v0.1.5, the v0.1.5-pre.7 preview was shared at the community meeting before promotion.
Impact / Why This Matters
Release notes reviewed before the release, including upgrade notes for accepted breaking changes, can change or disappear at publication.
The captain must diff the published notes against the preview and edit the release by hand.
Each stable release makes another inference call and adds a failure point: if Write Release Notes fails, the GitHub Release isn't created.
Proposed Design
Select Qualified Prerelease already identifies the qualified Pre-release run. Expose its run ID as a job output.
In stable publication, download that run's release-notes artifact and replace the pre-release tag with the stable tag (heading and install command).
Fall back to generating notes, as today, when the preview artifact is missing or expired.
Optionally add a Release input to force regeneration, for when PR Release Notes sections were edited after the preview.
Leave notes-only previews and pre-release previews unchanged.
Acceptance Criteria
Promoting a pre-release with a notes preview publishes that preview, with only the tag changed.
Promoting a pre-release without a preview still generates notes.
The release job summary says whether the notes were reused or regenerated.
CI.md and the release-captain skill describe the behavior.
Alternatives Considered
Pinning the model and lowering temperature: still not deterministic, and the PR set is already identical.
Editing the GitHub Release body after publication: works today, but it's manual and the published text is wrong until someone notices.
Activity
ci(release): reuse the promoted prerelease's release notes preview (N…