Product Versioning
Semantic Versioning
Versioning of each technical “Product” or asset (i.e. API, Design Principle(s), Data Library) is managed using Semantic Versioning 2.0.0.
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following patch version.
For example: 1.0.0-alpha.1 is a valid pre-release version.
Pre-release Labels
When FHIR API implementation guides are published, they MUST have an associated maturity label. These labels are based on the GDS development process stages and MUST conform to one of the labels defined in the FHIR-PUB-04: FHIR API Maturity ‘Publication Requirements’ section of the NHS FHIR Policy.
The labels documented in the GDS development process stages are:
- Discovery: a Feasibility study. A ‘No code’ development. Designed to find out what users are trying to achieve, any constraints, improvement opportunities
- Alpha: Develop prototypes and test with users. Could be minimal functionality and potentially prototypes for any options to determine which is best
- Private Beta: Working version and test with invited users. Handle real transactions and work at scale. ‘Invite only’ or regional. Must Pass assessment by business and technical SME’s
- Public Beta: All users can participate. Version unlikely to change substantially, but still needs further testing by a wider group of implementors before becoming live
- Live: The live phase is about supporting the service in a sustainable way, and continuing to iterate and make improvements
- Retiring: Implementors notified that the service is discontinued and not to be used for new developments
