Release Cycles
Last updated
Last updated
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 in your staging environments and conduct thorough testing before updating your production systems.
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.
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 .
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:
The snapshot number of a release version can be found on the page.
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:
These releases are intended for staging systems only and not for production systems.
They are not covered by the software maintenance contract.
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:
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.
These releases are password-protected. If you would like access, please contact our support team through the