Rust sort of already has this, though implemented in a worse way. They use 0.[major/minor].[minor/patch]. When the library author wants to indicate that their library is stable, they go to 1.0.0 and promise that they'll never make a breaking change.
The problem with that approach is that you never know if a change is major or minor, since many projects use the 0.A.B differently. Even if projects were standardized, you're missing some information compated to A.B.C or A.B.C.D.
Re:What's next for SemVer
by steveklabnik on Monday February 11, 2019 @03:12PM
(#19137821)
This is an additional thing I'd really like to gain clarity on in the spec itself. Given that ranges have no definition currently....
Oh, also
> they go to 1.0.0 and promise that they'll never make a breaking change.
That's not what 1.0 means; 2.0 can be produced with breaking changes.
I think GP means that as a cultural thing, the Rust/Cargo ecosystem has a strong aversion to breaking changes, and as a result tends not to do anything that would require a bump to 2.0.
Re:What's next for SemVer
by FichteFoll on Monday February 11, 2019 @04:32PM
(#19138539)
To me this is something that a changelog should clarify. SemVer is intended to be used by machines and a change in a major version should prompt a developer to take a look at the actual changes (i.e. the changelog) and whether they are affected by those.
Adding another number for this purpose still does not tell you whether your particular use case of a library received breaking changes or not.
That's why I like to use SemVer with a small twist - a fourth number prepended to the regular three: A.B.C.D.
`B`, `C`, and `D` are the regular SemVer Major, Minor, and Patch. But `A` is "Generation" - something you increment only for fundamental changes to the codebase .i.e. 2.0.0.0 is a different generation of the product than 1.7.45.4, while 1.8.0.0 is the same generation, only with some incompatible APIs.