SemVer says that a PATCH can only include backwards compatible changes which fix incorrect behavior. Less important is whether or not a bug has been fixed but w

SemVer says that a PATCH can only include backwards compatible changes which fix incorrect behavior. Less important is whether or not a bug has been fixed but whether anything other that internal behavior has changed. MAJOR versions can also be incremented when "substantial new functionality or improvements are introduced within the private code" which is really the cause for confusion and, in my opinion, should be removed from the SemVer standard. There's no semantic value to consumers when significant amounts of private code has changed except for the potentially heightened possibility of introducing bugs. Removing this would clear the confusion up altogether. But the ComVer contention is that bugs don't deserve special treatment. I disagree. Changes to behavior that fix something but don't change anything else are changes I'm likely to want to deploy while maintaining a system. I might be using a legacy version where the main branch has progressed but I still want to deploy PATCH releases for bug fixes for an older version when they become available. I do not want to upgrade by a MINOR version if I can avoid it because it would add functionality or interfaces I don't need and which themselves could be problematic. I want to make as little change as necessary to maintain a otherwise stable system. Minimizing the surface area of a release to only the necessary is an important principle to follow when publishing public APIs. Thinking about bug fixes as distinct from new features means you're considering every change in light of the potential impact to consumers. Even when know you don't have any actual dependent consumers, it's still a good habit of a disciplined engineer.