[sauceop]

I feel like a lot of semver purists have never maintained software with a lot of downstream dependencies. The gray area about what is a breaking change is huge and it's hard to usefully improve software without making changes that are breaking under some definitions. The broadest is that, if a downstream program was working against version x.y, then it should always work unmodified against x.z.

One obvious case is bug compatibility and undocumented behaviour - it isn't that uncommon for software to depend on bugs or undocumented/unintentional behaviour. But if you're exposing a language like SQL, it's even messier. E.g. if cockroach added a new feature to the SQL dialect, then it could break downstream software that was assuming a particular SQL string would return an error. Or if you extend existing functionality, say supporting a wider range of arguments in some function.

There's also unspecified behaviour and implementation details - e.g. if a query without an "order by" happened to reliably return rows in a particular order before an upgrade, but it changes after an upgrade because of an algorithmic change, is it a breaking change? Common sense would say no, because it's not documented behaviour, but pedants could disagree.

And of course there's performance changes - if a query runs 100x slower after an upgrade, but returns the same result, is that a breaking change?

If you take the most pedantic interpretation of semver, you either have to bump the major version number all the time or you are very limited in how you can improve the software.