Release identifiers and version control strategy

From HL7 TSC
Revision as of 16:13, 7 August 2007 by Charliemccay (talk | contribs) (New page: 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 committee...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.

Retrieved from "https://tscwiki.hl7.org/w/index.php?title=Release_identifiers_and_version_control_strategy&oldid=1976"