Release Cycles
his guide offers a detailed explanation of the various release types, their significance, how to access them, and the expected release schedule.
We strongly encourage our customers to deploy the latest versions in their staging environments and conduct thorough testing before updating their production systems.
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:
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:
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:
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.
Last updated