{"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":"<p>This <a href=\"http:\/\/www.w3.org\/QA\/2007\/12\/version_identifiers_reconsider.html\">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&#8211;though a significant revision to the core hasn&#8217;t happened and perhaps never will.<\/p>\n<p>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<p>Indeed, the idea seemed familiar in my mind. In fact, I posted it <a href=\"https:\/\/dubinko.info\/blog\/2004_02_01_archive.html#107622326951410859\">here<\/a>, in Feb 2004. The remainder of this posting republishes it with minor edits for clarity:<\/p>\n<p>&#8216;Standard practice&#8217; 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 &#8216;organic&#8217; approach is needed.<\/p>\n<p>For example, look at how browser user agent strings have evolved. Take this, for example:<\/p>\n<p>Mozilla\/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows 98) Opera 7.02 [en]<\/p>\n<p>Wow, if detection code is looking for a substring of &#8220;Mozilla&#8221; or &#8220;Mozilla\/4&#8221; or &#8220;Mozilla\/4.0&#8221;, or &#8220;MSIE&#8221; or &#8220;MSIE 6&#8221; or &#8220;MSIE 6.0&#8221; or &#8220;Opera&#8221; or &#8220;Opera 7&#8221; or &#8220;Opera 7.0&#8221; or &#8220;Opera 7.0.2&#8221; 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<p>Since this is the way of nature, don&#8217;t fight it with artificial, fixed-length major.minor versioning. Embrace organically growing versions.<\/p>\n<p>The first version of anything should be &#8220;1.&#8221; 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 &#8216;needs-to-know&#8217; basis. A check-this-version API would be extremely useful, though a basic string compare SHOULD work.<\/p>\n<p>Then, whenever revisions come out, the designers need to decide if the revision is compatible or not. A completely incompatible release would then be &#8220;2.&#8221;. However, a compatible release would be &#8220;1.1.&#8221;. All version checking code would continue to look only up to the first dot, <em>unless<\/em> it has a specific reason to need more details. Then it can go up to the 2nd dot, no more.<\/p>\n<p>Now, even code that is expecting version &#8220;1.1.&#8221; will work fine with &#8220;1.1.1.&#8221; or 1.1.86.&#8221; or &#8220;1.1.2.1.42.1.536.&#8221;.<\/p>\n<p>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<p>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 &#8220;Windows 4.9&#8221;).<\/p>\n<p>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<p>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":"<p>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&#8211;though a significant revision to&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_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}},"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":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p8eo8l-3z","_links":{"self":[{"href":"https:\/\/dubinko.info\/blog\/wp-json\/wp\/v2\/posts\/221","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dubinko.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dubinko.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dubinko.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dubinko.info\/blog\/wp-json\/wp\/v2\/comments?post=221"}],"version-history":[{"count":0,"href":"https:\/\/dubinko.info\/blog\/wp-json\/wp\/v2\/posts\/221\/revisions"}],"wp:attachment":[{"href":"https:\/\/dubinko.info\/blog\/wp-json\/wp\/v2\/media?parent=221"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dubinko.info\/blog\/wp-json\/wp\/v2\/categories?post=221"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dubinko.info\/blog\/wp-json\/wp\/v2\/tags?post=221"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}