Airlock Versioning Scheme

This article describes the versioning scheme of the Airlock products.

Goals and motivation:

• One versioning scheme for Gateway, Microgateway, and IAM
• Version number indicates expected upgrade effort
• Prevent misunderstandings regarding IAM STS-Releases

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

The "STS" label marks releases as "short-term support" releases. Releases without a label are implicitly LTS.
Please refer to https://techzone.ergon.ch/lifecycle for further information about the support life cycle.

Definitions of "Breaking Change"

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

• Invasive change, 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 on customers.
• Non-backward compatible changes in the control API (CAPI).
• If a full re-installation is necessary (e.g. major OS update).

Airlock Microgateway

• In case of invasive changes, they potentially require manual configuration changes or re-testing of already integrated applications (e.g. significant 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 (CAPI).
• Adjustments in the deployment mode.

Airlock IAM

If upgrading requires manual changes for existing features in the following areas:

• Documented REST APIs
• Configuration (XML, instance.properties, environment variables)
• Customizing (HTML/JSP templates, SDK)
• DB schemas