Release Version control

This page is to discuss the options for Release Version control, in order to identify a format that meets all requirements and has a minimal impact on users.

Requirements

Proposal

Definition

Release versioning will reflect the version of the release package, within the existing Product name/Release Date version standard, as follows:

This format includes all of the additional information required to quickly and uniquely identify the correct package to use at any one time, without adversely impacting any of the related policies (such as the Snomed CT URI standard, etc).

The major differences between this and the current versioning standard are as follows:

1. The "Release Status" component is added in, in order to quickly identify whether or not each package is Alpha/Beta/Production status - and avoid unintentional use of Alpha/Beta packages in Production systems.

2. The "Release date/time" component moves from being the effectiveTime of the Release (eg) 20160731, to being the actual published date and time of the Release (eg) 20160731T134500.  This will allow quick and painless distinction between different versions of the same release.  So, for example, if you have to recall and re-publish the July 2016 International edition, instead of having 2 different packages called "SnomedCT_InternationalRF2_INT_20160731.zip" (one original and one recall, and no quick way to identify which is which!), you would have the original package called "SnomedCT_InternationalRF2_Production_20160731T140000", and then the recall package (subsequently published on 11th August) called "SnomedCT_InternationalRF2_Production_20160811T120000".

Therefore, at any one time, the latest version of any product package can be identified by the fact that it has a Release Status equal to "Production", and a Release date and time later than all others of the same Product and Release Status.

This standard can therefore continue to be applied once Continuous Delivery has been implemented, as we will ensure that no roll-up releases are deployed on the same Release Date as the interim releases.  There may also be value in adding a word to the Release Status element at this point, in order to clearly distinguish between interim and roll-up releases - however this will be decided at the time and defined in the Continuous Delivery proposal.

Examples of versioned package names