[iopq]

Well, backwards-compatibility is sometimes a probability.

For example, a change in the public signature of a function to accept a wider class of arguments might be considered backwards-compatible since the previous calls to the function will still work.

But if your language has type inference, now the previous calls have to actually specify the type of their arguments since the type inference algorithm can no longer resolve all the types.

So you can break SOMEONE'S build by accepting more types of arguments. It will be a one line fix, but if that fix has to be made upstream...

[rmattes]

That's an interesting point. If you're using a language that adds more rules to the API compatibility than the language that a module is released in, it's probably not possible to rely on semver in the general case. Unless the author is aware of those issues and versioning accordingly, any minor release could be breaking.

[iopq]

Even in the same language, how do you prove that your changes didn't break things like type inference? Any change to the signature of a function (even accepting MORE types than before) can potentially break someone's code.

[rmattes]

If you can't definitively prove that a class of changes won't break things, then you probably have to treat that class of changes as breaking and version accordingly, no?