7

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.

10

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.

  • 1
    There's one thing you could add to this otherwise excellent answer. If the method were eg GetSomeCETTime, but it's returning an IST time, then it's a bug and so the patch number would be updated. – David Arno Jan 29 at 9:53
8

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.