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

No longer supported:

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.

Definition of breaking change

The term breaking change typically refers to a change that falls into one or more of the following categories:

  • Invasive change, potentially requiring manual configuration adjustment (e.g., new regex engine, removal of a deprecated feature)
  • Change in a Custom Resource Definition with apiVersion stable.
  • Non-backward compatible change in the control API.

Definition of non-breaking change

The term non-breaking change typically refers to a change that falls into one or more of the following categories:

  • Change in a non-published feature or feature marked as incubating (e.g., apiVersion not stable)
  • Change due an improved rule or parser that requires only a non-invasive adjustment
  • Change in log structure or metrics, as we provide built-in dashboards