Skip to content

fix(diff): flag 0.x minor bumps as breaking (semver initial-development rule)#48

Open
dmchaledev wants to merge 1 commit into
mainfrom
claude/magical-ptolemy-pg4u7c
Open

fix(diff): flag 0.x minor bumps as breaking (semver initial-development rule)#48
dmchaledev wants to merge 1 commit into
mainfrom
claude/magical-ptolemy-pg4u7c

Conversation

@dmchaledev

Copy link
Copy Markdown
Contributor

Summary

isMajorVersionBump() in src/diff.ts classified 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.0 allows 0.2.x but not 0.3.0), Cargo, and Composer: while the major is 0, a minor bump is a breaking change.

As a result, a very common class of upgrade was silently reported as safe:

// current main
isMajorVersionBump('0.1.0', '0.2.0') // => false  ❌ (this is breaking)

For a supply-chain risk tool, under-reporting breaking upgrades of the many 0.x packages in a typical dependency tree undersells the headline [MAJOR] / "Major? Yes" signal in every output format.

Change

isMajorVersionBump() now also flags a 0.x upgrade as breaking when the minor component increases while the major stays 0:

From To Before After
0.1.0 0.2.0 false true
0.2.0 0.2.1 false false (patch, unchanged)
0.9.0 1.0.0 true true (unchanged)
17.0.2 18.2.0 true true (unchanged)
4.17.20 4.17.21 false false (unchanged)

Version parsing is factored into a small parseVersion() helper that tolerates a leading v and pre-release/build suffixes (e.g. 2.0.0-beta). Downgrades are not treated as bumps. Behaviour for >= 1.0 versions is unchanged, so this is backward compatible for all post-1.0 dependencies.

Scope

Tests

npm test — 32 passing (added: 0.x minor bump ⇒ breaking, 0.x patch bump ⇒ not breaking, 0.x → 1.x graduation ⇒ breaking). Typecheck and lint clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QtAD7yBCFLNhvjcrWBtCQ4


Generated by Claude Code

…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
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.

2 participants