This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Versioning Strategies and Tactics

Stefan Tilkov,

Great food for thought from Bill de hÓra (and a very welcome pointer to Chris Ferris’s blog, which I followed for a long time but somehow lost my subscription to.) I agree with most of his points, although the last one (item 5) seems to be slightly misnamed for the whole bunch of stuff he puts into it :-) In any case, I have some disagreement here — I don’t think versioning was ever even remotely solved, or even properly addressed, in COM or J2EE (and I don’t think in .NET either), and I believe that while the very fact that interfaces and data formats become more explicitly exposed with Web services based APIs does indeed raise the stakes, it requires a more explicit thought process with regards to versioning (which is a Good Thing™).

Another very interesting thing is contained in one of his footnotes:

In Internet protocol design the default approach has been to reduce the risk of breakage by having highly constrained but highly generic interfaces.

This is, of course, the REST discussion all over again. Yet somehow I came to think about it in a way that was new (to me only, I am sure): Is it really a protocol change if I change e.g. an RPC-style WS operation name? Doesn’t that very much depend on my point of view, i.e. whether I write (or at least look at) my code as dependent on the lower-level protocol (which is always going to be one level more generic that my high-level protocol) or dependent on the higher-level protocol? In other words, is versioning — which is going to be a problem in both cases — the perfect example showing that the perceived REST/WS schism is maybe not that big a deal?