SemVer defines a special rule for the 0.y.z range that doesn't apply once a package reaches 1.0.0. What is that rule, and why do many popular libraries intentionally stay below 1.0.0 for years despite being widely used in production?

## Two regimes, split at 1.0.0 SemVer's specification explicitly separates two regimes: **'initial development,'** which covers any version where MAJOR is 0 (`0.y.z`, e.g. `0.1.0`, `0.9.4`), and the **stable regime** that begins the moment a project publishes `1.0.0`. In the `0.y.z` regime, the compatibility rules that normally apply to MAJOR/MINOR/PATCH are relaxed: the spec states the public API should not be considered stable, and changes — including breaking ones — may happen in a MINOR bump (`0.3.0` → `0.4.0`) without violating the contract, since there effectively is no MAJOR to protect yet. Only PATCH-level changes are still expected to be backward-compatible bug fixes; MINOR in the `0.x` range is essentially a looser 'meaningful new version' marker rather than a compatibility promise. The moment a project publishes `1.0.0`, this exemption disappears permanently, and full MAJOR/MINOR/PATCH discipline applies from then on. ## What 1.0.0 commits a maintainer to The mechanism exists because `1.0.0` is defined by the spec itself as a specific commitment: once your software is being used in production, it should probably already be `1.0.0`, and that release defines the public API. In other words, `1.0.0` isn't a marketing milestone — it's a promise that the API is now considered stable enough that any future incompatible change must be flagged with a MAJOR bump, and consumers can safely build long-lived automation around that promise. `0.y.z` exists precisely to give maintainers room to iterate on API design without prematurely making that promise. ## Why mature projects stay below it Why real, widely-used projects stay in `0.x` for extended periods despite heavy production adoption comes down to a trade-off between **signaling honesty** and **social/marketing pressure**. Committing to `1.0.0` while still uncertain about core API decisions locks a project into either breaking its own promise later, or freezing a design the maintainers already suspect is wrong, purely to preserve the appearance of stability. Staying at `0.x` is a deliberate, honest signal: you can and should use this, but budget time to read changelogs on every MINOR upgrade, because we haven't finished deciding what the shape of this API should be. This is common in fast-moving ecosystems — infrastructure tooling, new language toolchains, and libraries built directly on top of an unstable upstream spec often stay `0.x` specifically because their own stability is gated on something outside their control. ## What the consumer gives up The trade-off cuts both ways. From a consumer's perspective, `0.x` versioning removes the automated-upgrade safety net that MAJOR/MINOR/PATCH is supposed to provide: a caret range on a `0.x` package behaves differently in most tools — npm's `^0.4.2`, for instance, only allows PATCH-level bumps (`0.4.x`, not `0.5.0`), specifically because the ecosystem tooling has adapted to treat `0.x` MINOR bumps as unsafe, mirroring the spec's own initial-development carve-out. This means dependency resolvers effectively can't distinguish safe from risky MINOR upgrades within `0.x` the way they can for `1.x+`, so consumers of `0.x` dependencies get less automation value and more manual review burden, even if the package is otherwise mature and heavily used. ## Failure modes Failure modes show up in two directions. 1. **First**, teams sometimes misunderstand caret-range behavior for `0.x` dependencies and get an unexpected breaking MINOR bump because they assumed caret always protects across the whole leading digit, when for `0.x` it actually protects only PATCH-level changes, and for `0.0.x` it protects nothing at all — every change is potentially breaking. 2. **Second, and more organizationally**, some projects stay at `0.x` indefinitely as a form of liability-avoidance while behaving as a de facto stable dependency for thousands of consumers — this creates a mismatch between the version number's stated meaning and the ecosystem's actual expectations, and a genuine breaking MINOR release can then feel like a violated promise to users who'd stopped reading the `0.x` fine print. ## Where it shows up A well-known real-world instance: Kubernetes' client-go library and many CNCF ecosystem tools spent years at `0.x` versions specifically because their own API surface tracked an evolving upstream spec, while being depended on in production by major companies the whole time; more broadly, it's common to see foundational build/tooling packages linger at `0.x` for years past their de facto '1.0 in spirit' maturity precisely because the maintainers are wary of the permanence `1.0.0` implies.