A lot of the comments so far seem to be missing the point.
This appears to be simply saying that version numbers are misleading; what is important is not what version number is being used, but what contracts that version number corresponds to.
That is, it's more useful to say "This release adheres to standard A, B and C, and no longer supports D", and talk about interoperability that way, than it is to say "Version X requires talking to version (X-1) or later".
To borrow from a comment another made, I don't care what version my browser is, I -do- care if it supports Websockets or not (and what version, and what it sends across the connection, etc). This article is saying to describe your releases, and what changed in them, in those terms. As a client user of your software, I really don't care about what changes you make under the hood, -unless- they break the contracts I am dependent on. Version numbers obscure what changes matter to me, vs what ones don't, and are thus insufficient. They can, however, be helpful shorthand, if you document accordingly.
>> This appears to be simply saying that version numbers are misleading; what is important is not what version number is being used, but what contracts that version number corresponds to.
Indeed, the version number is just an attempt to draw a big circle around a whole set of statements about contractual compliance and give the set a meaningful label. As such they are often wrong, and really don't transmit much in the way of useful information.
I was surprised not to read more in the piece about the role of automated tests as an enforcer of contractual compliance.
This appears to be simply saying that version numbers are misleading; what is important is not what version number is being used, but what contracts that version number corresponds to.
That is, it's more useful to say "This release adheres to standard A, B and C, and no longer supports D", and talk about interoperability that way, than it is to say "Version X requires talking to version (X-1) or later".
To borrow from a comment another made, I don't care what version my browser is, I -do- care if it supports Websockets or not (and what version, and what it sends across the connection, etc). This article is saying to describe your releases, and what changed in them, in those terms. As a client user of your software, I really don't care about what changes you make under the hood, -unless- they break the contracts I am dependent on. Version numbers obscure what changes matter to me, vs what ones don't, and are thus insufficient. They can, however, be helpful shorthand, if you document accordingly.