This seems like a nice idea on the face of it, but it's a lot less simple (who decides what's major and what isn't) and plus, when you introduce a "small" break

This seems like a nice idea on the face of it, but it's a lot less simple (who decides what's major and what isn't) and plus, when you introduce a "small" breaking change you have no idea what impact that's going to have downstream. It could be a really big deal for a client. The fact that it's a breaking change by definition means it's going to be a problem for someone and you really have no way to know how deeply entrenched that small piece of API surface is. What bothers me about the current trends in release management is that there is way too much emphasis on iterating quickly, even for libraries where that's completely inappropriate. It's much better to just put all your breaking changes into an unstable branch and only merge to stable (and change version numbers) infrequently, when you're sure the dust has settled. Anyone that really needs the latest updates can pull the unstable branch at their own risk, but everyone else doesn't have their build broken every other day. This is a really serious problem in the JavaScript ecosystem right now (even disregarding the left-pad debacle).