"Any breaking change, no matter how small increments the Breaking version number. Incrementing the Breaking version number has absolutely no relationship with issuing a release."<p>Wow.<p>Am I only in thinking that this is seriously inadequate?<p>If you are <i>knowingly</i> making a change that "breaks" your installed base, there had better be a compelling (and well-explained) reason for it, along with advice how a user can detect if their code is affected and instructions on how to rework it.<p>Version numbers are not decoration. A user (and, more importantly, <i>your</i> support and engineering organizations) should be able to determine by the full (not necessarily front-page displayed, but available, like in an About tab) version number whether a given known bug affects them.
It's in fact an article on how to do software versioning "properly", which we kind of know...<p>The true problem is vaguely defined APIs with vaguely defined behaviors which are prone to change/be fixed/be upgraded during minor updates, which do not qualify as "breaking", because no one realises they do break compatibility.<p>So it's not so much about fixing your version numbers, it's about fixing your tests and specs. And only then you might be able to use the right versioning...