3 ms·

Why not just move to 3.0? Semver only says that a breaking change MUST be an increase to the major version. It doesn't proscribe an increase of the major versio

by devmop 7y ago

Why not just move to 3.0? Semver only says that a breaking change MUST be an increase to the major version. It doesn't proscribe an increase of the major version without a breaking change.

misterdoubt 7y ago
Yes! Semver is very precisely specified and the specification ain't very long. How on Earth could they mess it up?
- knz42 7y ago
  A point not highlighted in OP article is that Enterprise customers are shy to upgrade to a "next major version" because they will _assume_ there are breaking changes in there (even though semver allows bumping the major number without breaking changes). Calver side-steps this user bias.
  - AnIdiotOnTheNet 7y ago
    Why are developers always insistent on trying to trick the user into doing what they want them to do, or what they think is best, instead of letting users do what users want to do? Users shy away from major version numbers because they are allowed to change things in incompatible ways. When you jump a major version you're signaling that stuff might intentionally break, and they make their decisions accordingly. The solution is not to make your communication with user even worse!
    - soccerdave 7y ago
      This could easily be solved by something along the lines of “Version 3.0 maintains full compatibility with Version 2.2” at the top of their release notes. I dislike the idea of going away from SemVer just for marketing purposes. At least as a user when I’m going to upgrade versions then I could see that “oh, this version doesn’t break compatibility”
  - Dayshine 7y ago
    >Calver side-steps this user bias. Well, no, it just means users won't update at all, because every version could be breaking...
- lifthrasiir 7y ago
  Because its summary does not exactly agree to the specification. > Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.

by devmop 7y ago

Why not just move to 3.0? Semver only says that a breaking change MUST be an increase to the major version. It doesn't proscribe an increase of the major version without a breaking change.

misterdoubt 7y ago

Yes! Semver is very precisely specified and the specification ain't very long. How on Earth could they mess it up?

knz42 7y ago
A point not highlighted in OP article is that Enterprise customers are shy to upgrade to a "next major version" because they will _assume_ there are breaking changes in there (even though semver allows bumping the major number without breaking changes). Calver side-steps this user bias.
- AnIdiotOnTheNet 7y ago
  Why are developers always insistent on trying to trick the user into doing what they want them to do, or what they think is best, instead of letting users do what users want to do? Users shy away from major version numbers because they are allowed to change things in incompatible ways. When you jump a major version you're signaling that stuff might intentionally break, and they make their decisions accordingly. The solution is not to make your communication with user even worse!
  - soccerdave 7y ago
    This could easily be solved by something along the lines of “Version 3.0 maintains full compatibility with Version 2.2” at the top of their release notes. I dislike the idea of going away from SemVer just for marketing purposes. At least as a user when I’m going to upgrade versions then I could see that “oh, this version doesn’t break compatibility”
- Dayshine 7y ago
  >Calver side-steps this user bias. Well, no, it just means users won't update at all, because every version could be breaking...
lifthrasiir 7y ago
Because its summary does not exactly agree to the specification. > Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.