Airlock semantic versioning scheme
1.1. Semantic versioning scheme for Airlock Secure Access Hub components

A new versioning scheme is introduced for Airlock components in March 2020.

Affected components:

  • Airlock Gateway
  • Airlock Microgateway
  • Airlock IAM

About the new versioning scheme

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

IAM_semantic_versioning
  • Goals and motivation:
  • Same versioning scheme for all Airlock components.
  • The version number indicates the expected upgrade effort.
  • Prevent misunderstandings regarding STS releases.

The "LTS" label marks IAM releases as "long-term support" releases. WAF releases are implicit "LTS".
Please refer to https://techzone.ergon.ch/lifecycle for further information about the support life cycle.

Effects on upcoming releases

Upcoming Airlock Gateway releases are not affected.

The Airlock IAM releases in 2020 are versioned as follows:

Product
Old version
New version
Airlock IAM
7.2-pre1
7.2 STS
Airlock IAM
7.2 GA
7.3 LTS

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)
  • Customizing (HTML/JSP templates, SDK)
  • 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.).
  • Non-backward-compatible changes in the control API.
  • Changes in the DSL which requires to modify the configuration file manually.

Note that changes on non-published features or features marked as incubating are not considered breaking. These include IAM Loginapp SPA SDK, and IAM Java API for custom code (see Allow list document on Techzone).