As of Unblu 5, Unblu versions comply with the Semantic Versioning specification. Versions use a sequence of three digits (
<major>.<minor>.<patch>(.<qualifier>)) to describe the impact of an update of the software. The definition of impact in this scheme is usually measured in terms of public API, can also be described with the term “breaking changes”. In this scheme the version numbers and the way they change convey meaning about the underlying code - and what has been modified from one version to the next.
In summary the semantic meaning of the
<major>.<minor>.<patch> version scheme is defined as follows:
<major>digit increment is used when incompatible API changes are introduced,
<minor>digit increment is used when functionality is added in a backwards-compatible manner
<patch>digit increment is used when backwards-compatible bug fixes are being made.
Therefore Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.
Release versions are sparse (e.g after
5.1.6 the next public version might be
When the version is updated with an increment of the
<minor> digit (this is called "new minor version"), then there will be no patch update anymore for the previous versions (e.g when
5.2.0 is released, if the previous version was
5.1.5 there is no
In addition to the public releases, internal releases exist during development phase of a release stream.
Development versions: preview version published before feature freeze, released in the early development phase.
Stabilization versions: after feature freeze, released before the first public version of a stream.
Alpha and beta versions only for major releases, there is no
Hotfix versions: if a customer needs an hotfix, then it is using the pattern: