Yes. The Semantic Versioning specification says major version zero (0.y.z) is for initial development and that anything may change at any time. A 0.4.1 to 0.5.0 bump can break your code even though only the minor number moved. Treat every 0.x update as potentially breaking.
What the specification actually says
Semantic Versioning defines three numbers. MAJOR changes when the API changes in an incompatible way. MINOR adds functionality in a backward compatible manner. PATCH is a backward compatible bug fix. The specification then carves out an exception: major version zero is for initial development, and the public API should not be considered stable.
Version 1.0.0 is the point where the public API is defined. After that, the way numbers go up depends on how that API changes.
So the promise you may be relying on, that a minor bump is safe, only starts at 1.0.0. Before that, the author has made no such promise.
Why this matters for update automation
Most update bots read the version change and label it patch, minor or major. They do that by comparing numbers, not by reading the code. For a package at 1.x or higher that label is a useful hint. For a package at 0.x it can mislead you, because a 0.x minor bump is allowed to carry breaking changes.
A practical consequence: a rule such as "auto-merge all minor updates" quietly includes the riskiest class of change, which is a 0.x minor.
A simple rule table
| Current version | Update type | Treat as |
|---|---|---|
| 1.x or higher | patch | Low risk, normal checks |
| 1.x or higher | minor | Usually safe, read release notes |
| 1.x or higher | major | Breaking by definition, plan work |
| 0.x | patch | Usually a fix, run tests |
| 0.x | minor | Possibly breaking, review like a major |
| Any | pre-release | Unstable, do not merge to main by default |
The pre-release row comes from the same specification. A pre-release version, such as one with an alpha label, is marked as unstable and sorts below the normal release with the same numbers.
Steps to handle 0.x dependencies
- List the direct dependencies whose version starts with 0. Your lockfile or SBOM gives you this in one query.
- Add a bot rule that excludes 0.x minor updates from any auto-merge group. Route them to normal review instead.
- For each one, read the changelog before merging, and check whether the project has a stated policy for what its minor releases may change.
- Ask whether the package is really still in initial development, or whether the maintainers simply never moved to 1.0.0. Some very widely used packages sit at 0.x for years, so the number alone tells you little about quality.
- Pin or cap the range for packages you cannot afford to have move. A range that accepts any newer minor is a bet that the author keeps compatibility.
What this does not tell you
Semantic Versioning describes a promise, not a guarantee. Authors make mistakes, and a patch can break behavior someone depended on. The version label narrows your review, it does not replace tests.
Also note that the exact behavior of range operators such as caret on 0.x versions is defined by your package manager, not by the specification. Check your tool's documentation before relying on a particular reading.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how many flagged dependencies are never called, which is the same triage question you ask of a 0.x update: does my code actually touch the changed part?
Quick check
Is 0.9.0 to 0.10.0 a minor update?
By number, yes. By promise, no. Under major version zero anything may change at any time, so review it as if it could break.
Does 1.0.0 guarantee no breaking changes ever?
No. It means the public API is defined and that later breaking changes should come with a new major number. It is still a promise from the author, so keep your tests.
Safeguard scans manifests and lockfiles into an SBOM, uses reachability analysis to show which flagged dependencies your code actually calls, and can open fix pull requests (off by default, every category on Manual). You can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
