v2+ Vocabulary
0.2.0 - Working Draft to present the concept ideas (FO)

v2+ Vocabulary - Local Development build (v0.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Versioning Policy for v2

Originally, i.e. during the v2 Tables Project we have used an integer to denote the version of a table with regard to its content. That implies, that incompatible next versions need to have a different base name respectively OID. However, it is hard to further argue in this direction.

From v2 Tables Project

Formerly, the project decided to use positive integers to version tables. Consequently, a new version is expressed by increasing this number by 1. Unfortunately, a version change does not tell anything about the type of change, i.e. whether it is major or only minor, or compatible or incompatible. Incompatible changes are introduced by new OIDs and symbolic names. This ia hard to maintain correctly.

SEMVER - semantic versioning

Versioning has to be independent from the base version of the standard. Therefore, semantic versioning semver.org seems to be reasonable, but it requires detailed inspection of all tables.

That implies changing the version information for tables from integer to major (integer) + minor (integer) + patch (string).

Standard translation from old to new:

old   new
empty -> 0.0.0
x -> x-1.0.0

It is important to note that incompatible changes in a codesystem require a specific notation. Major changes in semver does that!


type explanation major minor patch
symbolic name a short symbolic name for usings that a specific concept domain, value set or codesystem      
OID a unique identifier introducing the origin      
namespace useful?      

Use of Symbolic Names

Is it necessary to have different symbolic names for a new major version for semantic incompatible changes?

Use of Namespaces

It is unclear what namespaces are good for in this project/endavour?

Use of OIDs