Repository navigation
fix: list only the changes since the previous prerelease with the same name in each prerelease changelog section, instead of repeating everything since the last stable release. Stable releases, and the first prerelease with a new name, still list everything since the last stable release. (fixes #349) - #350
Open
TimothyJones wants to merge 1 commit into
Open
TimothyJones wants to merge 1 commit into
TimothyJones wants to merge 1 commit into
Conversation
…e name in each prerelease changelog section, instead of repeating everything since the last stable release. Stable releases, and the first prerelease with a new name, still list everything since the last stable release. (fixes #349) Since 13.1.1 (#310) the changelog window always started at the last stable tag, so a continued prerelease repeated every earlier prerelease's entries and its compare link pointed at the stable tag. The window now starts at the most recent tag that is stable or a prerelease with the same identifier as the version being released. The tag list is filtered in a ConventionalGitClient subclass passed to ConventionalChangelog, so the commit range, section splits and compare links all use the same boundaries. The bump calculation is unchanged. A switched identifier (dev -> rc) deliberately stays cumulative, as the #310 tests assert, rather than reverting to "last tag of any kind". Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.
Fixes #349.
Problem
Since 13.1.1 (#310) the changelog window always started at the last stable tag. That is right for a stable release, but a continued prerelease (
alpha.1→alpha.2) repeated every earlier prerelease's entries, and its compare link pointed at the stable tag.Change
A changelog section now starts at the most recent tag that is either stable or a prerelease with the same name as the version being released.
alpha.1→alpha.2)alpha.1dev.0→rc.0)dev.0,rc.0,dev.1)dev.0The third row differs from the "last tag of any kind" suggestion in the issue. The #310 tests assert it deliberately, so I kept it.
The tag list is filtered in a
ConventionalGitClientsubclass passed toConventionalChangelog, so the commit range, section splits and compare links all use the same boundaries. The bump calculation is untouched.Testing
v1.0.0.test/prerelease-window.integration-test.js: the "continues a prerelease with the same identifier" test asserted the cumulative behaviour and is flipped; added the issue's three-alpha scenario followed by a stable release, and the return-to-a-name case.npm testpasses (156 tests, lint, prettier).Docs
New README section "What Each Changelog Section Covers". The neighbouring "Keeping Prereleases out of a Final Changelog" section is not changed here; it predates the #310 fix and may want a follow-up.
🤖 Generated with Claude Code