Release and support information

Release lifecycles

Bugfix releases for minor versions will be served for 9 months from the release date of the respective minor version for important bugs and critical security issues.
This support plan starts with Airlock Microgateway 4.2.

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.

Customers should continually update their installations to the newest maintenance and minor releases to profit from hotfixes and support. For versions out of support, we will remind customers to upgrade.

Support lifecycle for Airlock Microgateway minor releases:

Minor version

Published

End-of-support

4.5

02/2025

11/2025

4.4

10/2024

07/2025

4.3

07/2024

04/2025

4.2

04/2024

01/2025

Hotfixes and security updates

Critical security and availability issues for Airlock Microgateway will be fixed in a timely manner for each of the supported release versions. It is at Ergon's discretion to decide which issues will receive a hotfix or maintenance version update.

  • Security scanners might detect vulnerabilities in our product:
  • Hotfixes will be served forexploitable vulnerabilities within the bugfix support​.
  • For vulnerabilities that cannot be exploited (e.g., false positives), maintenance versions are provided once a month as part of the bugfix support so that scanners are no longer triggered.

Incubating features in Airlock Microgateway

From time to time, a release of Airlock Microgateway may include what we call Incubating features in Airlock Microgateway. 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:
  • x is the major version.
  • y is the minor version.
  • z is the patch version.
  • This scheme follows the Airlock semantic versioning terminology.

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 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 with apiVersion stable.
  • Non-backward-compatible changes in the control API.
  • Adjustments in the deployment mode.
  • 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.