Repository navigation
ci(release): start a stable release's notes at the previous stable tag - #418
Merged
Merged
Conversation
The release workflow generated the changelog entry and release notes from the highest existing tag. Once a release candidate is tagged, that is the candidate, so promoting it to stable diffed the release commit against its own candidate: v0.7.0 would have covered zero commits, and git-iris fails on empty notes. A stable version now starts from the previous stable tag, so its notes cover everything since then, its candidates included. Prereleases keep starting from the latest tag, and a first stable release with only candidates before it still falls back to the latest candidate. The workflow test returns the step's outputs and pins all three cases; on the previous workflow the stable case fails. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reached
This review includes 2 billable files and costs up to $0.50. Or wait 25 minutes for your next included review. View limit details
Comment |
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
1 participant
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.
Promoting a release candidate to stable would ship near-empty release notes. The release workflow generates the changelog entry and release notes from the highest existing tag, and once
v0.7.0-rc.1exists, that tag is the candidate itself. Cutting0.7.0would diff the release commit againstv0.7.0-rc.1, a range of zero commits, and git-iris fails on empty notes before anything is pushed. This is the first time the repo has tagged a candidate, so the path had never run.A stable version now starts its notes at the previous stable tag (
v0.6.3for0.7.0), covering everything since then, its candidates included. Prereleases keep starting at the latest tag, and a first stable release with only candidates before it falls back to the latest candidate.🧪 Validation
node --test scripts/tests/release-workflow.test.mjs0.7.0starts atv0.6.3;0.7.0-rc.2would start atv0.7.0-rc.1actionlint .github/workflows/release.ymlOnce this merges, the 0.7.0 cut runs a dry run first so the generated notes can be checked before anything is pushed.
🤖 Generated with Claude Code