5 ms·

> The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and thos

> The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and those on 2.1 would know that they could upgrade to it without worrying about fixing their own integrations. No. Semver states quite clearly that "Major version MUST be incremented if any backwards incompatible changes are introduced to the public API.". It does NOT state that the Major verson MUST NOT be incremented if the api has no backwards incompatible changes. You can increment the MAJOR component of the version number at your will. So this is quit clearly a 3.0.0 release. Or it could be a 40.0.0 release and it would still be valid semver.

StavrosK 7y ago
By that interpretation, their calendar versioning (19.1.0) is also valid semver, because there's no rule about NOT just incrementing whatever whenever.
- cormacrelf 7y ago
  Except that for it to remain both valid calver and valid semver, they would have to delay all breaking changes until January every time they come up.
  - StavrosK 7y ago
    They seem to indicate that they aren't expecting any more breaking changes, but yes, that's generally true.
- Legogris 7y ago
  It's not valid if 19.2 introduces breaking changes form 19.1
- trickstra 7y ago
  true, but doing that makes no sense, because people who made their software depend on major v18 are not switching automatically, because they first need to check if any breaking changes happened and if they need to modify their own software. Semver is "semantic" for a reason - to simplify this daunting task. Increasing major version even when there are no breaking changes is technically still semver, but without the helpful warranty, so it completely misses the point
codetrotter 7y ago
IMO it’s kind of implied by semver that a major version increment means breaking changes. If you increment major version without breaking changes then you aren’t really doing semver IMO. It’s like if you have a fire alarm that goes off when there’s a fire but which also goes off randomly all of the time. People are going to stop listening to it, because even though it reliably rings when there’s a fire the fact that it rings is unlikely to mean there’s an actual fire. In the same way, if you keep incrementing the major version without breaking changes then people can no longer rely on the version number to be alerted about breaking changes. By all means, increment your major version number when you feel like it. Just don’t call it semver. Because even if you are technically allowed to, it goes against the spirit / point of semver IMO.
- rhizome 7y ago
  I agree, people shouldn't be afraid of v3.27.0
- donmcronald 7y ago
  Just add an unnecessary breaking change and everything's perfect.
  - jspash 7y ago
    This is the correct answer! IMHO. A perfect solution that strikes the balance between an engineer's unrelenting desire for correctness and the marketing departments seemingly irrational need for perceived progress.
- pvinis 7y ago
  I think the key part of your answer is "IMO". Incrementing the major without breaking is still semver, where wether you think so or not. One example for you is a package that was javascript and moved to typescript. Same everything, but they increment the major.
  - kakwa_ 7y ago
    Sometimes, it makes sense to increment MAJOR for a significant change, like a complete rework of the code, even if it's purely internal and doesn't break the API. In such cases, even if nothing is supposed to change "on paper", it will probably have an impact (different performance, lower stability for the few first MINORs/PATCHs, etc). But incrementing MAJOR on a yearly basis, if the major only changes by year, doing dep=X.* in your requirements.txt/package.json/Gemfile doesn't make much sense, if one of my dependencies has not significantly changed, why should I increase a version number in my dependency manager? It's just unnecessary work. It can also raise interesting existential question if you have to release a version with a breaking change (let say, a security fix that necessitate a change in the API). What do you do then? If you don't increase MAJOR, you don't follow semver, if you increase it, you break your versioning pattern, and release 20.0 in 2019.

StavrosK 7y ago

By that interpretation, their calendar versioning (19.1.0) is also valid semver, because there's no rule about NOT just incrementing whatever whenever.

cormacrelf 7y ago
Except that for it to remain both valid calver and valid semver, they would have to delay all breaking changes until January every time they come up.
- StavrosK 7y ago
  They seem to indicate that they aren't expecting any more breaking changes, but yes, that's generally true.
Legogris 7y ago
It's not valid if 19.2 introduces breaking changes form 19.1
trickstra 7y ago
true, but doing that makes no sense, because people who made their software depend on major v18 are not switching automatically, because they first need to check if any breaking changes happened and if they need to modify their own software. Semver is "semantic" for a reason - to simplify this daunting task. Increasing major version even when there are no breaking changes is technically still semver, but without the helpful warranty, so it completely misses the point

codetrotter 7y ago

IMO it’s kind of implied by semver that a major version increment means breaking changes. If you increment major version without breaking changes then you aren’t really doing semver IMO. It’s like if you have a fire alarm that goes off when there’s a fire but which also goes off randomly all of the time. People are going to stop listening to it, because even though it reliably rings when there’s a fire the fact that it rings is unlikely to mean there’s an actual fire. In the same way, if you keep incrementing the major version without breaking changes then people can no longer rely on the version number to be alerted about breaking changes. By all means, increment your major version number when you feel like it. Just don’t call it semver. Because even if you are technically allowed to, it goes against the spirit / point of semver IMO.

rhizome 7y ago
I agree, people shouldn't be afraid of v3.27.0
donmcronald 7y ago
Just add an unnecessary breaking change and everything's perfect.
- jspash 7y ago
  This is the correct answer! IMHO. A perfect solution that strikes the balance between an engineer's unrelenting desire for correctness and the marketing departments seemingly irrational need for perceived progress.
pvinis 7y ago
I think the key part of your answer is "IMO". Incrementing the major without breaking is still semver, where wether you think so or not. One example for you is a package that was javascript and moved to typescript. Same everything, but they increment the major.
- kakwa_ 7y ago
  Sometimes, it makes sense to increment MAJOR for a significant change, like a complete rework of the code, even if it's purely internal and doesn't break the API. In such cases, even if nothing is supposed to change "on paper", it will probably have an impact (different performance, lower stability for the few first MINORs/PATCHs, etc). But incrementing MAJOR on a yearly basis, if the major only changes by year, doing dep=X.* in your requirements.txt/package.json/Gemfile doesn't make much sense, if one of my dependencies has not significantly changed, why should I increase a version number in my dependency manager? It's just unnecessary work. It can also raise interesting existential question if you have to release a version with a breaking change (let say, a security fix that necessitate a change in the API). What do you do then? If you don't increase MAJOR, you don't follow semver, if you increase it, you break your versioning pattern, and release 20.0 in 2019.