> If I didn't change the behavior with any set of input parameters valid for the prior version, I haven't broken compatibility. You don't anticipate that the b

> If I didn't change the behavior with any set of input parameters valid for the prior version, I haven't broken compatibility. You don't anticipate that the behavior will change in a way that you care about, but that's not the same as not changing behavior. Different sides of an API nearly always have different definitions of "valid" and "behavior" here, and API documentation is never as concrete as would be needed to prevent that. So are you exhaustively fuzzing the input space? Because if you are, then great. But I bet you aren't. And even if you are, nobody else is. > more than 0% of real software projects using SemVer... I carefully said approximately. It gives us some leeway when talking about this without falling into the trap of believing that a small degree of adherence is meaningful. > feature releases may be assumed to have greater risk of expanding the risk surface I know it's common for people to feel that way, but there isn't a meaningful interface safety dividing boundary that any of us can point to between development of a feature vs a fix. Code is code is code is code. The developers can either reliably identify when changes will break users or not. If they can, then breaking.nonbreaking is plenty. If they can't, then only a single newer_than_before value is fine. Like, if you want to argue for a new Dragonwriter's TrustVer where we talk about degrees of belief about whether a change will break something, we can do that. I'm all for it. But more than two values will still not be more useful to the user than at most two (except in the one contractual obligation case I presented), and it won't be Semver.