Below 1.0, the minor number is the breaking one

Foxstash 0.9 removed a public storage mode. Anyone whose code named it gets a compile error on upgrade. That's a breaking change, so the release is 0.9.0, not 0.8.1.

That sounds obvious. It wasn't written down anywhere until this week, and the reason it matters below 1.0 is not the reason most people think.

What the caret actually does

When you add a dependency in Rust, cargo add writes something like foxstash-core = "0.8.0", which Cargo reads as ^0.8.0. npm writes "^0.8.0" outright. Both mean "this version, plus anything compatible with it". And both decide compatibility the same way:

Below 1.0, the caret treats the second number as the one that breaks things. So a dependent pinned to ^0.3.4 picks up every 0.3.y the next time anyone runs an update or builds without a lockfile, and refuses 0.4.0 until a person chooses it.

That makes the version number a promise. Ship a breaking change as 0.3.5 and it lands in every dependent's next build, unasked, and breaks it. Ship it as 0.4.0 and it waits until they opt in. The number is the only signal they get.

The rule

Semantic versioning, shifted one place while the major version is zero:

Below 1.0 there's no separate slot for features, so features and fixes share the last number. That loses a little information. It's the price of keeping the one signal that matters, "this will break you", in the position the tools actually read.

Two more lines go with the table.

Going to 1.0 is a decision, not a counter. It means the public API is stable. It shouldn't happen because a run of features rolled the number over.

Tell your release tool. By default, release-please treats a breaking change below 1.0 as a jump straight to 1.0.0, and bumps the minor on every feature, which under this rule marks every feature as breaking. Set bump-minor-pre-major and bump-patch-for-minor-pre-major to true and it follows the table.

Where it lives now

My company's software lifecycle procedure now has this table in its release stage, and a release isn't done until the version bump matches the type of change. The yearly internal audit checks it: for each sampled release, compare the commits since the last tag, and if any were breaking, the minor number had better have moved. The same table sits in the knowledge base my build machines read, word for word, because those machines can't see the company drive where the procedure lives.

Foxstash 0.9.0 was the first release after the rule was written down. It's breaking, it bumped the minor, and anyone on foxstash-core = "0.8" stays on 0.8 until they decide to move.

What I'd tell you if you were buying this work

If you depend on a library that's still below 1.0, read its changelog before each minor upgrade, and check whether the maintainers treat the minor number as the breaking one. If you're paying someone to ship a library to you, ask how they number releases and what stops a breaking change from going out as a patch. "We're careful" isn't an answer. A rule someone audits is.