Release Cycles

This guide provides a detailed explanation of different release types, their significance, how to access them, the expected release schedule, and the supported version path.

We strongly encourage our customers to deploy the latest versions. Please check the Release Notes in your staging environments and conduct thorough testing before updating your production systems.

Supported Versions of Helmut4

Any reported bugs that are fixed will only be included in the latest or next release of Helmut 4.

Due to software maintenance, we actively support the last two previous versions alongside the current one. For example, if the current release is v4.7.x, the supported Helmut 4 versions are: v4.5.x, v4.6.x, and v4.7.x.

Staging license

Customers with a valid support contract are entitled to a staging license. If you wish to request yours, please contact our support team via our support portal.

Stable Releases

A stable release is published approximately every three to four months, specifically designed for deployment in production systems. This release is covered by the Helmut4 support contract.

To update to a stable release, access your Helmut server console and enter the following command with admin privileges:

helmut-snapshot <snapshot_version_number>

#example for Helmut 4.7.2
sudo helmut-snapshot 4.7.2

The snapshot number of a release version can be found on the changelog page.

DEV Releases

Development releases are provided during the development of each stable release to give ourDevelopment releases are provided during the development of each stable release to offer our customers early access to bug fixes and features.

To update to a stable release, access your Helmut server console and enter the following command with admin privileges:

sudo helmut-update

These releases are password-protected. If you would like access, please contact our support team through the support portal

Disclaimer DEV Releases

These releases are intended for staging systems only and not for production systems.

They are not covered by the software maintenance contract.

Semantic versioning

Helmut version 4.1.0 introduced a significant change in the way we version our backend components. We started using semantic versioning for all of our microservice endpoints.

The versioning format is as follows:

Helmut_Version.Major_change.Minor_change.Patch

To better understand how this convention is applied, consider the following example: during the development of release 4.1.0, if we perform bug fixes in the Streams container, the shipped Docker container will have version 4.1.0.2.

However, if we introduce any breaking changes that are not backward compatible, we will ship the Streams container with version 4.2.0.1.

Because the backend microservices are completely decoupled from the product version (currently at version 4), there may be mixed version numbers for a single snapshot, such as a container with version 4.3.0.1 in the 4.5.0 product release.

Taking this into consideration, it is expected for a stable release to include new versions of some containers while others remain untouched.

This strategy results in shorter downtime and fewer untagged/unused, but still cached, images on the host system.