> You increment b when you change something in a backwards compatible way. Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-

> You increment b when you change something in a backwards compatible way. Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-trivial development could lead to changes in behavior (or at least in performance) that, while not part of API contract, could still be relevant for users. For that reason, it makes sense to have a.b.c scheme, where 'b' is for regular backwards-compatible development, while 'c' is for targeted bugfix releases, which are hopefully devoid of such behavioral changes.