Under semantic versioning, a patch bump promises backward compatible bug fixes, a minor bump adds compatible features, and a major bump may break the API. That order is a useful first guess at risk for a fix PR, but it is a convention, not a guarantee, so verify rather than trust.
What the spec actually says
The Semantic Versioning 2.0.0 specification defines:
- Patch (x.y.Z): only backward compatible bug fixes, meaning internal changes that correct incorrect behavior.
- Minor (x.Y.z): new backward compatible functionality, or deprecation of public API features. Substantial improvements in private code may also bump it.
- Major (X.y.z): backward incompatible changes to the public API.
- 0.y.z: initial development. The spec says anything may change at any time.
Notice that a minor bump can mark features as deprecated. That is not breaking yet, but it is a signal that your next upgrade may be.
Where the promise breaks
Maintainers differ. Some treat any behavior change as major. Others ship breaking changes in minors. The spec describes a public API; if you rely on something the maintainers consider internal, a patch can still break you.
Security fixes change behavior on purpose. Closing a vulnerability sometimes means rejecting input that used to be accepted. That is correct, and it can still break a caller who relied on the old behavior.
Transitive effects. A patch release of one package may depend on a newer release of another. The version label on the package you named says nothing about what moved underneath. Always read the lockfile diff.
Pre 1.0 packages. Treat every bump as potentially breaking.
A practical risk guide
- Patch, 1.0 or later: Low risk; Light review, check lockfile
- Minor, 1.0 or later: Low to medium; Read release notes, run targeted tests
- Major: Medium to high; Read the migration guide, test in staging
- Any bump on 0.y.z: Medium; Treat like a major
- Any bump with a changelog entry about security behavior: Medium; Check callers of the changed API
This table is a starting assumption and your own history should adjust it. If patch bumps from a particular vendor keep breaking you, move that vendor to a higher tier. The approval tiers guide shows how to turn this into rules.
Prefer the smallest fixing version
A vulnerability is usually fixed in a specific release. If a patch release contains the fix, a PR that jumps to the latest major is taking on risk the finding does not require. Ask the tool, or the author, why. Sometimes the answer is good: the fixed line is end of life and only the new major is supported. Then the major jump is justified, and the review should say so.
Pinning and ranges
If your manifest uses a range like a caret or tilde, a lockfile decides which exact version installs. A fix PR for a range dependency often only needs a lockfile change. That is the cheapest fix, discussed in lockfile only fix versus manifest change.
Quick check
Is a patch update always safe to auto merge?
No. It is lower risk by convention. Check that required tests pass and that the lockfile diff holds no surprises.
Why do 0.y.z versions need extra care?
The spec says anything may change at any time in that range, so a minor or patch bump can break callers.
Safeguard's fix PRs state the target version and the finding being fixed, which gives you what you need to apply the guide above.
Sources
Last reviewed: 19 October 2026.
