Semver-major version bump does 3 things:
- Prevents automatic updates
- Allows multiple copies of the crate in the dependency tree
- Makes types from each major version incompatible
For big breaking changes, like major API redesigns, the combo of all (1+2+3) features is usually very useful and desirable.
However, for small breaking changes that are technically-breaking-but-not-really (bug fixes with side effects, API changes that are mostly backwards-compatible except rare cases) only the first point is useful to prevent surprises, but (2) and (3) are unnecessary and may be even quite undesirable for crates that have something "global", like shared types for interoperability between crates, manage global process state, or use the
Just reviewing compatibility of a dependency and bumping the version could be something that every user of the crate can do individually on their own schedule. However, when semver-major also makes APIs and types of the old and new versions incompatible, that creates a network effect that forces all users to coordinate the upgrade, or else applications may end up with multiple copies of the crate and type errors, conflicts or other side effects of that.
I wonder if there's a room for some Cargo feature for "small" breaking changes. Something that requires crates to opt-in to a technically-breaking update (1), but that doesn't break compatibility between new and old version (2+3).