Currently pretty much every maintainer has such a different idea of what constitutes a major/minor/patch change that I don’t really trust any version number to be insightful about the size of the change or difficulty updating to the new version until I’ve followed a library for a while and have seen several releases from the same person. As soon as you add a new standard for versioning someone will question if something really is a major enough breaking change or not or if they’ve been stuck on one epoch for too long or long enough and we’re back at the exact same situation as current.

Also, my view is that it’d be better if a version was comprised of 4 numbers instead of 3:

<marketing/product version>.<breaking changes>.<feature add-on>.<fix>

Making my point. Both were breaking in their early existence.

If you have found the new better interface, I bet it is to be named distinctly.

Because a better interface automatically leads to a better name? When I switch the argument order, there is no need for a new name and it would be worse to give it a ‘forced’ new name while the ‘old’ one was perfectly describing the function in the shortest way.

Plant warning for obsoletion

Again: in new libs it is polution imho . Break early and take the penalty. Once you are ‘too big to fail’ there will be enough times you have to ‘polute’ the code base with functions obsoletion. Just as you can see in both examples you provided. Breaking-strategy when small, obsoleting when larger.

That’s all I gotta say. Back on topic: epoch semver!