Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Guide Versioning

An overview of how this Implementation Guide is versioned

1. Product Versioning

1.1.0 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.

1.2.0 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:

  • Experimental: Early development/POC version of an API for early sight during discovery
  • Alpha: Initial test APIs, likely to change substantially, or be discontinued as the project develops
  • Release Candidate: APIs that are largely complete, unlikely to change substantially, but still need further testing before becoming live
  • Live: Release live APIs
  • Discontinued: APIs which have been discontinued and should not be used for new development.
Tags: development

All content is available under the Open Government Licence v3.0, except where otherwise stated