No. Semantic versioning says minor releases add functionality in a backward compatible way, but that is a promise from the maintainer, and promises get broken by mistake or by differing definitions of compatibility. Treat minor bumps as low risk, not zero risk, and keep a light test in front of them.
What the specification says
The Semantic Versioning specification defines the scheme as MAJOR.MINOR.PATCH. Increment MAJOR for incompatible API changes, MINOR for functionality added in a backward compatible manner, and PATCH for backward compatible bug fixes. It also says version 0.y.z is for initial development, where anything may change at any time and the public API should not be considered stable.
Two points follow. The scheme works only if the maintainer declares a public API clearly and follows the rules. And the zero-major range makes no stability promise at all.
Myth versus fact
| Myth | Fact |
|---|---|
| Minor bumps cannot break my build | They should not break documented behaviour, but mistakes happen |
| Patch bumps are always safe | Backward compatible bug fixes can still change behaviour you relied on |
| Every package follows semver | Many do not, and some use other schemes |
| 0.x versions are stable enough | The specification makes no stability promise for them |
| If tests pass, we are done | Tests cover what you wrote tests for |
Why compatible changes still break things
Google's chapter on dependency management describes Hyrum's Law: with enough users, every observable behaviour of an interface will be depended on by somebody. A fix that is correct by the documented contract can still break a caller who relied on the old, undocumented behaviour. Semver cannot see that dependence, because it sits in your code, not in the maintainer's API.
How to plan around it
- Route by risk, not by label. Let patch and minor updates through a fast lane with automated tests, and send majors through planned work. Our guide to reading patch, minor and major in a fix PR goes deeper.
- Be cautious with zero-major packages. Treat each minor bump as potentially breaking.
- Read the changelog for anything touching your hot paths. A thirty-second skim catches many surprises.
- Group low-risk bumps, but keep groups small. If one fails, you should be able to find the cause quickly.
- Use staged rollout for services where a silent behaviour change would hurt.
What to put in your plan
- A fast lane for patch and minor bumps with required CI checks.
- A rule that packages below version 1.0 are reviewed as if each bump were major.
- A rollback step in the runbook, for the day a safe-looking bump is not. See rolling back a bad dependency upgrade safely.
Estimating without semver
If you budget upgrade effort purely by version number, expect error in both directions. A large major with few API changes may be trivial, and a minor bump in a package you rely on heavily may hurt. Estimate from your own usage: how many places call into the package, and how well are they tested?
Where Safeguard fits
Safeguard's autonomous remediation can propose fix pull requests for vulnerable dependencies. It is off by default with every category on Manual, and your own CI decides what merges. A free scan is at gold.safeguard.sh/scan.
Quick check
Should minor bumps skip review?
They can skip lengthy review if CI is strong, but a quick look at the changelog and a passing test run is still sensible.
What is Hyrum's Law in one line?
With enough users of an interface, someone will depend on every observable behaviour, whether or not it was documented.
Sources
Last reviewed: 19 October 2026.
