Release Cycles
This guide provides a detailed explanation of the different types of releases, their meanings, how to access them, and the expected release schedule.
We encourage our customers to deploy the newest versions to their staging environment and perform 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 every three months (March, June, September, and December) 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:
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 our customers early access to bug fixes and features. These releases are intended for staging systems only and not for production systems. They are not covered by the software maintenance contract
To update to a stable release, access your Helmut server console and enter the following command:
These releases are password-protected. If you would like access, please contact our support team through the support portal
The snapshot number of a release version can be found on the changelog page
Semantic versioning
Helmut version 4.1.0 introduced a significant change in the way we version our backend components, as we began 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 some bugfixes 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 downwards 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