Release identifiers and version control strategy

From HL7 TSC
Jump to navigation Jump to search

There is a requirement to be able to maintain major, minor, and errata release branches for specifications. Major releases being those that introduce substantial new concepts, minor releases being tactical changes to introduce a limited number of features to an established release, and errata releases being for clarification or technical corrections only. It should be possible for committees to maintain a number of such branches for each specification.


This issue has come up with the Wrappers R2 project in InM and also the XML ITS revisions within the ITS SIG.

The following has been a request sent to the T3F on 31/7/2007 asking for guidence in this:

We (the ITS SIG) addressed a ballot naming issue that we feel does not have clear and consistent rules for all committees, and would like the T3F to review and identify affected committees for discussion/approval. We believe MnM, Publishing, Marketing, InM, ITS, SOA, StrucDoc may be stakeholders.

As some of you may know, the ITS SIG has been attempting to ballot a chapter for XML ITS Structures that is a point release from the current XML ITS Structures R1. AT issue was that we would prefer R1.1, but recognize that the ballot artifact policy/rule with ANSI is that only integral release numbers should be used. In this case, this is at odds with the underlying intent of the ballot to actually be "version 1.1". We have another unrelated "New XML ITS" to be published in the future.

Woody recommeded that we simply entitle the ballot "XML ITS ... 1.1" Release N. Where the release number is bumped and the title contains the spec number.

After much gnawing about this, we elected to call our ballot "XML ITS ... Strctures 1.1 Release 1". If we have a new point release, it will be "XML ITS ... Structures 1.2 Release 1". Only in the event of a technical correction would we bump the actual release number for a specification (e.g. "XML ITS ... Structures 1.1 Release 2")

This achieves an unambiguous separation of specification and document.