Semantic Versioning

Question

If a change compiled/built but the semantics were different would it be considered a major change?

For example, suppose a time string returned was the same format but now was CET rather than, say, IST and that interpreting it as IST now produced erroneous results would it be classified as MAJOR?

Note that I assume there is no change to the build, everything compiles and builds as before and everything runs without errors being detected just as before; its just that the 'answer' is now wrong, not right. I can't seem to find a consistent view.

Answer 1

Semantic versioning doesn't apply exclusively to the build system or API interface. It also applies to what the software does and how it interacts with other things.

If you make a change that breaks existing clients, that is very clearly an incompatible API change. It doesn't matter that you haven't changed the names of functions or arguments, or whatever. The way those functions work changed in a non backwards compatible manner, so you need a new major version, or need to do something else to preserve backwards compatibility.

Answer 2

Assuming that your changed function belongs to the public API, it appears that your new API version no longer provides the same result for the same input. This is definitely not backward compatible and hence requires a major change (see point 8 of Semantic Versioning):

Major version (...) MUST be incremented if any backwards incompatible changes are introduced to the public API

It is by the way clear that your change doesn't fit the requirements for the minor change:

Minor version (...) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code.

If you would provide the new behavior as an additional functionality (new function with a different name or new overload) and keep the existing one unchanged, you could go for a minor version. In this case you could even mark the previous one as deprecated, in order to allow for a soft transition to the new API, without breaking any code that uses (and works well) with the old version.