1.4.2 only communicates something if package authors treat compatibility as a promise. Calling a breaking change “minor” turns version ranges into roulette for everyone downstream.
Short answer: under semantic versioning, increment major for incompatible public API changes, minor for backwards-compatible features, and patch for backwards-compatible fixes. Before 1.0.0, consumers should assume the API is still unstable unless you document otherwise.
| Change | Version bump |
|---|---|
| Fix incorrect output without API change | Patch: 1.4.2 → 1.4.3 |
| Add optional API capability | Minor: 1.4.2 → 1.5.0 |
| Remove or change public behavior | Major: 1.4.2 → 2.0.0 |
{ "dependencies": { "example-lib": "^1.4.2" } }
The caret range accepts compatible 1.x updates but not 2.0.0. That is convenient only when the publisher honors the contract. Commit a lockfile for applications so a reproducible deploy does not depend on what appeared in the registry this morning.
Deprecation is often the cheapest major-version mitigation: document the replacement, warn consumers, then remove it in the next major rather than surprising them in a patch release.
Versions are communication. Make the number match the risk your consumers are taking.
Cover photo by Pixabay on Pexels.