Version Identifiers and XML

Norm Walsh carries on the discussion of DaveO's essay on Version Identifiers and XML here and here.

Norm makes the comment about Dave's suggestion that XML1.1 be called XML2.0 because of its lack of backwards-compatibility:

One can argue that it should have been called 2.0 because of its tiny backwards incompatibility, and that's an entirely valid argument, except that it ignores the fact that all specifications are developed in both a social and a technical context.

Here's a rule that could help: Version identifiers should be rigorously used to identify compatible or incompatible changes.

Yep, that would have made it 2.0. But users have non-technical expectations about version numbers and it's not clear to me that the community would have benefitted from the larger number. Maybe the lesson here is that putting version numbers in the title of your specification muddies the waters.

This reinforces the argument I made last month that use of version numbering schemes to convey forwards- and/or backwards-compatibility is misguided.

What many specifications have done though is to document the changes that break forwards- and/or backwards-compatibility. It would be nice if subsequent versions of all specifications would make formal statements to this effect in the front-matter where developers can easily find it (without having to wade through all the details of the spec).

Update: DaveO strikes back. However, his points reinforce my position that version numbers not be imbued with any semantic.

Norm and Chris Ferris both point out that the choice of version identifiers has various stakeholders - Chris points out the J2SE version identifiers - and various criteria - Norm points out the cost of implementation. I agree with all of that, but I'm pointing out that people using (sic) think of version identifiers being associated with compatibility.

Who would be the arbiter of the various positions of all the various stakeholders?

As for the case of XML1.x, Dave makes an important point. It isn't enough to simply add a version identifier in your vocabulary and expect that serves as a coherent versioning strategy that will permit forwards- and/or backwards-compatibility. Any software needs to have a coherent versioning strategy baked into the initial version. Version 2.0 (or 1.1, or 1.0.1, or whatever) is too late. By then, the horses have already left the barn. When calculating the TCO and ROI for a software project that does not have a coherent plan for enabling loosely coupled versioning that can enable forwards- and/or backwards-compatible changes, the initial deployment cost (at least) should be used as a measure for the inevitable version dot next and added to the overall support cost. That'll wake up a few bean-counters and make it clear to senior manglement that there is a real cost associated with NOT doing the right thing in the first place.