4 ms·

What I don't like about SemVer is that all breaking changes look exactly the same. That's why I like to use SemVer with a small twist - a fourth number prepend

What I don't like about SemVer is that all breaking changes look exactly the same. 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.

Amelorate 8y ago
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.
- steveklabnik 8y ago
  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.
  - lmkg 8y ago
    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.
FichteFoll 8y ago
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.

Amelorate 8y ago

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.

steveklabnik 8y ago
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.
- lmkg 8y ago
  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.

FichteFoll 8y ago

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.