[pvinis]

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_]

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.