I am currently developing a new library for RESTful web requests in Puredata, and am about to release version 1.0.0. This version will not implement all HTTP verbs, only GET, PUT, POST and DELETE.

In the next version, this library will most likely include the other HTTP verbs for RESTful requests, PATCH, HEAD, OPTIONS, CONNECT, TRACE.

I am using Semantic Versioning for the version numbers.

In the specs it says:

Minor version Y (x.Y.z | x > 0) 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. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

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.

Now, I am unsure what to after implementing the remaining verbs: On the one hand, the functionality is backwards compatible, as the already implemented functionality does not change. On the other hand, the functionality is changing, as issuing a HEAD request will not result in an error message on the console, but in an output. In the first case, only an increase to the minor version is needed, in the second case, the major version must be increased.

What is the correct interpretation in this case?

  • 1
    Possibly related: programmers.stackexchange.com/questions/133470/… Commented Dec 19, 2013 at 20:57
  • 4
    Going by your reasoning, adding a new foo resource at some level to your API should then also bump the major version number, as the behaviour changes from returning an error to returning a resource. I would not classify adding something that was previously unsupported as a backwards-incompatible change. Commented Dec 20, 2013 at 7:32

2 Answers 2


I think this matter only come to client relationship, sometime major mean pay more if you want to update

When come to Developer breaking API should mean changing to major version,

if you really want to implement all verb in one go, then use major version but if you want to push it slowly one verb at a time then minor should be enough


That's mostly a matter of what you consider a minor or major change. If you consider this to be only a minor improvement, you bump the minor version. If it's a big step you bump the major version.

In this case, (mind that I don't know the library), you probably want to bump the major version number. It looks like a big step when you start supporting different verbs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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