Skip to content

fix(ci): scope RC release notes to the previous RC - #267

Open
EtienneLescot wants to merge 1 commit into
release/v1.9.0from
fix/rc-release-notes
Open

fix(ci): scope RC release notes to the previous RC#267
EtienneLescot wants to merge 1 commit into
release/v1.9.0from
fix/rc-release-notes

Conversation

@EtienneLescot

@EtienneLescot EtienneLescot commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator

Problem

Every RC of a line ships the same release body. v1.8.0-rc.8 and v1.8.0-rc.9 are byte-identical; v1.9.0-rc.2 repeats all 18 of rc.1's entries before its own. The one question an RC body has to answer — what changed since the last RC — is the one it doesn't.

Two independent causes:

1. The notes start tag is derived from the stable version. STABLE_VERSION="${VERSION%%-*}" strips -rc.N, so every RC of 1.9.0 gets v1.8.0 as its start tag and spans the whole release.

2. --generate-notes lists only PRs GitHub manages to associate, and it drops real ones. #254 and #261 were both merged into release/v1.9.0 and both are in the rc.2 tag, yet neither appears in rc.2's body. Five of the eleven commits in v1.9.0-rc.1..v1.9.0-rc.2 are invisible — including fix(export): stop drawing the screen inside the PiP box on camera-less clips. An RC body can silently omit the fix it was cut for.

Fix

  • Resolve the previous RC of the same line as the start tag, walking down from the current rc number so a skipped or failed RC doesn't break the chain. rc.1 still falls back to the previous stable.
  • Build the RC body from git log over that range. The commit range is the actual diff and can't lie.
  • Stable releases are untouched — they keep --generate-notes for PR links and New Contributors.
  • fetch-depth: 0 on the publish job's checkout, needed for the tags and history.

What rc.2 would have looked like

## Changes since v1.9.0-rc.1

- fix(ci): sign the macOS .app ad-hoc when no certificate is available
- fix(recording): stream the native webcam to disk instead of losing it
- test(recording): make the re-index suite run off Linux
- fix(ci): notarize release candidates like stable releases
- fix(build): declare all 13 supported locales in the AppX package
- ci(macos): reject a MAC_CSC_NAME that carries its certificate type
- fix(recording): stop the WGC helper from hanging on stop
- fix(recording): stop a webcam finalize from discarding the screen capture
- ci(diagnostic): build the bundle for release branches too
- fix(export): stop drawing the screen inside the PiP box on camera-less clips
- fix(layout): resolve the webcam layout per clip, not once per timeline

Verification

Ran locally against the real tag graph:

  • start-tag resolution: rc.1 → v1.8.0, rc.2 → v1.9.0-rc.1, v1.9.0 → v1.8.0, v1.8.0-rc.9 → v1.8.0-rc.8, and an unstarted line falls back correctly.
  • the notes block dry-run under GitHub's shell flags (set -eo pipefail) for the prerelease path, the stable path, and an empty range — the last one being the set -e risk, since git log over an empty range is what a re-tag would hit. All exit 0.
  • YAML parses; both edited run: blocks pass bash -n.

Targets release/v1.9.0 so an rc.3 gets it immediately; reaches main through the usual back-merge at promote.

Every RC of a line shipped the same release body. The notes start tag was
derived from the stable version, so v1.9.0-rc.1 and v1.9.0-rc.2 both spanned
v1.8.0..<tag> — rc.2 just repeated rc.1's list plus its own few entries, and
v1.8.0-rc.8 and rc.9 came out byte-identical. Testers had no way to see what a
re-cut actually changed, which is the one question an RC body has to answer.

Resolve the previous RC of the same line instead, walking down from the current
rc number so a skipped or failed RC doesn't break the chain. rc.1 still falls
back to the previous stable, and stable releases are untouched.

Build the RC body from `git log` rather than --generate-notes. GitHub's
generator lists only the PRs it manages to associate and silently drops real
ones: #254 and #261 were merged into release/v1.9.0 yet never appeared in
v1.9.0-rc.2's body, so an RC could omit the very fix it was cut for. The commit
range is the actual diff. Stable releases keep --generate-notes — they are the
public-facing ones and want the PR links and the New Contributors section.

Needs fetch-depth: 0 on the publish job's checkout for the tags and history.
@coderabbitai

coderabbitai Bot commented Aug 5, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: ca4e1de3-461f-4e7c-910b-0bd4f65d7759

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant