fix(release): fold the beta changelog into the release that supersedes it - #219
Merged
Merged
Conversation
…s it The 5.1.0 release PR reads as though almost nothing shipped: ## [5.1.0] Bug Fixes, Documentation, Chores - 3 entries ## [5.1.0-beta] Features, Bug Fixes, Performance, ... - 33 entries release-please writes one section per release and a prerelease is a release, so everything that went into 5.1.0 sits under a heading for a version almost nobody installed. Someone upgrading 5.0.1 -> 5.1.0 wants one list. Prerelease sections are now folded into the stable release with the same major.minor.patch, with the subsections put back into the order changelog-sections declares - merging appends whole groups, so without that a reader meets Chores before Features. The compare link widens to where the earliest prerelease started, since the stable release now spans it. Only the topmost section is considered, which is the release being prepared. Folding every stable release rewrote history on the first run: it merged the 2022 4.0.0-alpha.0 and 4.0.0-alpha.1 sections into 4.0.0 and lost which alpha introduced what, in releases that shipped years ago. Also fixes the branch name this step works on. It was hardcoded to `release-please--branches--main`, which stopped being the release branch when removing `separate-pull-requests: false` gave the strategy its own name - `release-please--branches--main--components--monorepo`. A hardcoded name does not fail, it silently skips, so the changelog was quietly going untidied. It is now read from the open release pull request. Verified against the real release branch: 3 + 33 = 36 entries with none lost, subsections in canonical order, the 4.0.0 alphas untouched, a second run a no-op, and the deduplicator finding nothing left to remove afterwards. Co-Authored-By: Claude <noreply@anthropic.com>
Merged
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.
You're right — as it stands the 5.1.0 release PR reads as though almost nothing
shipped:
release-please writes one section per release, and a prerelease is a release.
So everything that actually went into 5.1.0 sits under a heading for a version
almost nobody installed. Anyone upgrading 5.0.1 → 5.1.0 wants one list.
Fix
Prerelease sections are folded into the stable release sharing their
major.minor.patch, with subsections restored to the orderchangelog-sectionsdeclares — merging appends whole groups, so without that areader meets Chores before Features. The compare link widens to where
the earliest prerelease began, since the stable release now spans it:
Only the topmost section is considered — the release being prepared. My
first version folded every stable release and rewrote history: it merged the
2022
4.0.0-alpha.0and4.0.0-alpha.1sections into4.0.0, losing whichalpha introduced what, in releases that shipped years ago.
A second bug, found while wiring it up
The step's
RELEASE_BRANCHwas hardcoded torelease-please--branches--main.That stopped being the release branch when #216 removed
separate-pull-requests: falseand the strategy started naming its own —release-please--branches--main--components--monorepo.A hardcoded name doesn't fail, it silently skips: the
git ls-remoteguardsimply found nothing, so the changelog was quietly going untidied. It is now
read from the open release pull request, so it survives future config changes.
Verified against the real release branch
4.0.0-alphasections untouchedno prerelease sections to fold— idempotentNote
This is general, not a one-off patch — but it should rarely fire again. Betas
are now manual dispatches that publish to npm without a tag or a GitHub Release,
so they no longer produce changelog sections at all.
🤖 Generated with Claude Code