Release and support information

Release lifecycles

Patch releases for minor versions will be served for 9 months from the release date of the respective minor version.

End-of-support dates (EOS)

Supported releases are covered by the Airlock support process. That is, customers and partners may open support cases for these versions, and our support team will investigate these issues.

Support lifecycle for Airlock Microgateway minor releases:

Minor version

Published

End-of-support

4.7

08/2025

05/2026

4.6

05/2025

02/2026

4.5

02/2025

11/2025

4.4

10/2024

07/2025

Bugfixes and security updates

Critical security issues and bugfixes for Airlock Microgateway will be fixed in a timely manner for each of the supported release versions. Once a month a patch release is provided that covers non-exploitable vulnerabilities and necessary updates of dependencies.

Incubating features in Airlock Microgateway

From time to time, a release of Airlock Microgateway may include what we call incubating features. Such features allow customers to explore new technologies or aspects of Kubernetes and Microgateway-related functionalities or DevSecOps and Zero-Trust innovations.

What sets incubating features apart are the following properties:

  • Incubating features are often based on draft standards that may change over time and, therefore, require breaking changes in the feature. Such changes may be included in minor product versions.
  • Incubating features are intended for proof-of-concept implementations to explore new and innovative solutions.

Release artifacts

We might provide additional artifacts that can be used with Airlock Microgateway. This may comprise documentation, examples, tutorials, etc. Generally, these artifacts are only maintained for the most recent version. Nevertheless, it is at Ergon's discretion to decide which artifacts are also maintained for older versions.

Airlock semantic versioning

Airlock Microgateway versions are expressed as x.y.z:

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

Specific definitions of breaking changes:

  • Invasive changes, potentially requiring manual configuration changes (e.g. new regex engine, removal of deprecated features, etc.).
  • Changes in Custom Resource Definitions with apiVersion stable.
  • Non-backward-compatible changes in the control API.

Specific definition of non-breaking changes:

  • Non-published features or features marked as incubating (e.g. apiVersion not stable)
  • Improved rules or parsers that require non-invasive changes.
  • Adjustments in log structure or metrics, since we provide built-in dashboards.