One of the problems here is recursive cross dependencies--libfoo switches to a major upgrade of libacme 2.x, while libbar remains with 1.x. Even in a language o

One of the problems here is recursive cross dependencies--libfoo switches to a major upgrade of libacme 2.x, while libbar remains with 1.x. Even in a language or environment where 1.x and 2.x could in theory coexist, the potential for bugs is often significantly increased. Ideally, before someone decides to inflict their open source code upon the world, they should at least nominally commit to 100% backwards API compatibility. That sets the correct frame of mind, both as a maintainer but also wrt designing and implementing your API. For example, these days all new syscalls on Linux are expected to have a flags argument and strictly reject undefined combinations of flags and arguments. There are exceptions, but that's the baseline expectation; even when excepted, those expectations help steer the conversation to expose potential compatibility traps. And they do this because Linux nominally promises 100% backward compatibility, regardless of versioning; though it took them many years to appreciate the need for those particular technical guard rails. If and when you need to break your promise of 100% backward compatibility (as even Linux occasionally does), then use Semantic Versioning to help smooth the way and set expectations. (I'm agnostic, but certainly semantic versioning was normative long before "Semantic Versioning" existed.) But if your answer to API compatibility starts with Semantic Versioning, then I wouldn't want to have anything to do with your library. It's like asking a bank what their approach to risk management will be and they answer, "following regulatory guidelines". It's not actually a substantive answer to the question, and suggests that one should avoid that bank.