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.

Just add an unnecessary breaking change and everything's perfect.

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.

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.

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.

I agree, people shouldn't be afraid of v3.27.0

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

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.

They seem to indicate that they aren't expecting any more breaking changes, but yes, that's generally true.

It's not valid if 19.2 introduces breaking changes form 19.1

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