While writing a different post, I had a thought about point 8 of the Semantic Versioning (SemVer) specification.

8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

The term "backwards incompatible change" is interesting here because it doesn't specifically reference interfaces and contracts between two pieces of code - a "backwards incompatible change" can just as easily be a behavioural change of the code base.

Consider the following for an example of a behavioural code change:

Initial code:

function encodeText(text) {
    return text.replace('a', 'xyz');
}

New code:

function encodeText(text) {
    return text.replace('a', 'xyz').replace('b', 'foo');
}

Contractually, the code is the same as it is still called encodeText, still takes one argument and still returns a string. Its behaviour on the other hand isn't as now additional text is encoded too.

Let's take it one step further, what about bug fixes?

For a bug fix, you are changing one set of behaviours for another (unintended behaviour to intended behaviour). The original bug may never have been intended but given it is now in the wild, it might now be depended to act that way.

You might be thinking that is a little extreme and I agree. If bug fixes were considered breaking changes because they are a behavioural change, there would be a lot more major versions for libraries.

So question time:

1. Should behavioural changes be counted as a type of breaking change?
2. If yes to above, should bug fixes be counted as a breaking change?