{"id":221,"date":"2007-12-31T23:14:37","date_gmt":"2008-01-01T06:14:37","guid":{"rendered":"https:\/\/dubinko.info\/blog\/2007\/12\/31\/should-documents-self-version\/"},"modified":"2007-12-31T23:14:37","modified_gmt":"2008-01-01T06:14:37","slug":"should-documents-self-version","status":"publish","type":"post","link":"https:\/\/dubinko.info\/blog\/2007\/12\/should-documents-self-version\/","title":{"rendered":"Should documents self-version?"},"content":{"rendered":"

This blog page at the W3C<\/a> discusses the TAG finding that a data format specification SHOULD provide for version information, specifically reconsidering that suggestion. As a few data points, XML 1.1 (with explicit version identifiers) is something of a non-starter, while Atom (without explicit version identifiers) is doing OK so far–though a significant revision to the core hasn’t happened and perhaps never will.<\/p>\n

In a chat with Dave Orchard at XML 2007, I suggested that the evolution of browser User-Agent strings might be a useful model, since it developed in response to the actual kinds of problems that versioning needs to solve.<\/p>\n

Indeed, the idea seemed familiar in my mind. In fact, I posted it here<\/a>, in Feb 2004. The remainder of this posting republishes it with minor edits for clarity:<\/p>\n

‘Standard practice’ of x.y.z versioning, where x is major, y is minor, and z is sub-minor (often build number) is not best practice. If you look at how systems actually evolve over time, a more ‘organic’ approach is needed.<\/p>\n

For example, look at how browser user agent strings have evolved. Take this, for example:<\/p>\n

Mozilla\/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows 98) Opera 7.02 [en]<\/p>\n

Wow, if detection code is looking for a substring of “Mozilla” or “Mozilla\/4” or “Mozilla\/4.0”, or “MSIE” or “MSIE 6” or “MSIE 6.0” or “Opera” or “Opera 7” or “Opera 7.0” or “Opera 7.0.2” it will hit. If you look at the kind of code to determine what version of Windows is running, or the exact make and model of processor, you will see a similar pattern.<\/p>\n

Since this is the way of nature, don’t fight it with artificial, fixed-length major.minor versioning. Embrace organically growing versions.<\/p>\n

The first version of anything should be “1.” including the dot. (letters will work in practice too) All sample code, etc. that checks versions must stop at the first dot character; anything beyond that is on a ‘needs-to-know’ basis. A check-this-version API would be extremely useful, though a basic string compare SHOULD work.<\/p>\n

Then, whenever revisions come out, the designers need to decide if the revision is compatible or not. A completely incompatible release would then be “2.”. However, a compatible release would be “1.1.”. All version checking code would continue to look only up to the first dot, unless<\/em> it has a specific reason to need more details. Then it can go up to the 2nd dot, no more.<\/p>\n

Now, even code that is expecting version “1.1.” will work fine with “1.1.1.” or 1.1.86.” or “1.1.2.1.42.1.536.”.<\/p>\n

Every new release needs to decide (and explicitly encode in the version string) how compatible it is with the entire tree of earlier versions.<\/p>\n

Now, as long as compatible revisions keep coming out, the version string gets longer and longer. This is the key benefit, and why fixed-field version numbers are so inflexible. (and why you get silly things like Samba reporting itself as “Windows 4.9”).<\/p>\n

One possible enhancement, purely to make version numbers look more like what folks are used to, is to allow a superfluous zero at the end. This the first version is 1.0, followed by 1.1.0, 1.1.1.0, (this next one made an incompatible change) 1.2.0, and so on.<\/p>\n

So if a document needs to self-version at all, perhaps a scheme like this should be used? -m<\/p>\n","protected":false},"excerpt":{"rendered":"

This blog page at the W3C discusses the TAG finding that a data format specification SHOULD provide for version information, specifically reconsidering that suggestion. As a few data points, XML 1.1 (with explicit version identifiers) is something of a non-starter, while Atom (without explicit version identifiers) is doing OK so far–though a significant revision to…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[33,3,9,4],"tags":[],"class_list":["post-221","post","type-post","status-publish","format-standard","hentry","category-annoyance","category-patternalia","category-standards","category-xml"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t