fix(diff): flag 0.x minor bumps as breaking (semver initial-development rule)#48
Open
dmchaledev wants to merge 1 commit into
Open
fix(diff): flag 0.x minor bumps as breaking (semver initial-development rule)#48dmchaledev wants to merge 1 commit into
dmchaledev wants to merge 1 commit into
Conversation
…nt rule) isMajorVersionBump only compared the numeric major component, so a bump like 0.1.0 -> 0.2.0 was reported as a non-breaking upgrade. Under semver's "initial development" clause — honoured in practice by npm's caret range, Cargo, and Composer — a minor bump while the major is 0 is breaking. For a supply-chain risk tool, silently marking these common pre-1.0 upgrades as safe undersells the [MAJOR] risk signal. Now while the major is 0, an increase in the minor component is flagged as a major/breaking bump; 0.x patch bumps stay non-breaking, and >=1.0 behaviour is unchanged. Parsing is factored into a small parseVersion helper that tolerates a leading "v" and pre-release/build suffixes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QtAD7yBCFLNhvjcrWBtCQ4
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.
Summary
isMajorVersionBump()insrc/diff.tsclassified a bump as breaking only when the numeric major component increased. That misses semver's initial-development rule for the pre-1.0 (0.x) range, which is honoured in practice by npm's caret ranges (^0.2.0allows0.2.xbut not0.3.0), Cargo, and Composer: while the major is0, a minor bump is a breaking change.As a result, a very common class of upgrade was silently reported as safe:
For a supply-chain risk tool, under-reporting breaking upgrades of the many
0.xpackages in a typical dependency tree undersells the headline[MAJOR]/ "Major? Yes" signal in every output format.Change
isMajorVersionBump()now also flags a0.xupgrade as breaking when the minor component increases while the major stays0:0.1.00.2.0falsetrue0.2.00.2.1falsefalse(patch, unchanged)0.9.01.0.0truetrue(unchanged)17.0.218.2.0truetrue(unchanged)4.17.204.17.21falsefalse(unchanged)Version parsing is factored into a small
parseVersion()helper that tolerates a leadingvand pre-release/build suffixes (e.g.2.0.0-beta). Downgrades are not treated as bumps. Behaviour for>= 1.0versions is unchanged, so this is backward compatible for all post-1.0 dependencies.Scope
isMajorVersionBumpinternals insrc/diff.tsand adds tests. The publicVersionChange.isMajorBumpfield, the reporter, and the CLI are unchanged.Tests
npm test— 32 passing (added:0.xminor bump ⇒ breaking,0.xpatch bump ⇒ not breaking,0.x → 1.xgraduation ⇒ breaking). Typecheck and lint clean.🤖 Generated with Claude Code
https://claude.ai/code/session_01QtAD7yBCFLNhvjcrWBtCQ4
Generated by Claude Code