> people seem to be very fearful of being the guy who introduced a breaking change in a minor increment, so they increment the major whenever they are not suffi

> people seem to be very fearful of being the guy who introduced a breaking change in a minor increment, so they increment the major whenever they are not sufficiently confident that there can't be a corner case where an API consumer would break Again, see the point about not having a well-defined API. (Again, this is taking issue with SemVer when you're not actually practicing it. But let's say I bend the rules a bit: what you suggest is fine, really. If you inadvertently bump a major and describe what the change is s.t. I can account for whether it breaks me — that's ok. As good as what SemVer wanted, no, but still better than just arbitrary versioning. There's likely still some subset of changes that you can reasonable assume are non-breaking. A commit that does linting only? Not going to break your API.) > Since that corner case is almost universally possible (e.g. your new API extension's names might collide with names an API consumer might have foolishly declared under your namespace In the few languages where this is possible, it is almost always implicitly not part of the API. E.g., in Python… if you're monkey-patching members/attribtes inside another package and that causes breakage — SemVer is not your problem here. You're going to have issues under any versioning scheme.