Semantic versioning scheme for Airlock Secure Access Hub components

This article describes the versioning scheme of the Airlock products.

Affected components:

Airlock Gateway
Airlock Microgateway
Airlock IAM

About the versioning scheme

The versioning scheme is based on semantic versioning with specific definitions of breaking change:

Goals and motivation:
One versioning scheme for Airlock Gateway, Microgateway, and IAM.
The version number indicates the expected upgrade effort.

Specific definitions of breaking changes

Semantic versioning requires a release to be major whenever it contains breaking changes. We adhere to the following definitions of breaking change.

A version is considered to be breaking and, therefore a major release in the following cases:

Airlock Gateway	In case of invasive changes, potentially requiring manual configuration changes or re-testing of already integrated applications (e.g. major rule or parser changes, new regex engine, removal of deprecated features, etc.). Changes in the config REST API with expected high impact for customers. Non-backward-compatible changes in the control API. If a full re-installation is necessary (e.g. major OS update).
Airlock IAM	If upgrading requires manual changes for existing features in the following areas: Documented REST APIs Configuration (XML, instance.properties, environment variables) Loginapp Design Kit DB schemas
Airlock Microgateway	In case of invasive changes, potentially requiring manual configuration changes or re-testing of already integrated applications (e.g. major rule or parser changes, new regex engine, removal of deprecated features, etc.). Changes in Custom Resource Definitions which have the `apiVersion` stable. Non-backward-compatible changes in the control API. Adjustments in the deployment mode.

Changes on non-published features or features marked as incubating are not considered breaking.