Skip to content

ci(release): reuse the promoted pre-release's release notes preview for stable releases #4753

Closed

Description

@matthewgrossman

User Story

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

  1. added a commit that references this issue on Oct 20, 2026
    0f5b4f0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions