Checkmk versions

On the development branch (in the Git’s version control this is referred to as the ‘master’), Checkmk’s future is being developed. So that developers, users and other interested parties can at any time get an impression of the current state of the software, every day between 0:00 and 6:00 Middle European Time an installations package for all supported Linux distribution versions will be created. These packages are called daily builds, Git snapshots or developer versions, and they represent the exact state of the software’s development at the start of every day.

The daily builds will naturally often contain some bugs, since it contains a more or less ‘random’ snapshot of the current state of the software. In contrast to the innovation and stable versions, daily builds also generate no new development branch, and thus cannot be patched by us. The only way to correct an error in a daily build, is to replace it with a newer daily build which may have it’s own problems. For this reason a daily build should never be used for a production environment.

Nevertheless, the daily builds are very useful if you as a user wish to try out new features in real time. This is especially applicable if you yourself have commissioned us to develop the feature!

Our support is also happy to help with difficulties with daily builds, but under the following restrictions:

Innovation versions are a special feature of the Checkmk Enterprise Editions and give you the possibility to use new and interesting features in the software long before the next stable version is released. The innovation versions represent a compromise between stability and new features.

As a rule the first innovation version becomes available about half a year after the last stable release. Over the following 1-2 months, 3-4 releases will be produced, each identified in sequence by an i number (e.g., 1.6.0i2). Similarly to stable versions, these will also be actively maintained – but only for a limited time of around 1-2 months, which is then followed by a similar period of passive maintenance. Patches of i-versions can be recognized by a p-suffix, e.g., 1.6.0i2p1.

Innovation versions are not covered by break-fix support.

The release of a new stable version, (e.g. 2.0.0), begins with a beta phase. In order to correct all errors, and to make the software production ready, an additional stable branch containing only error corrections will be split off. Development of features for future versions continues in parallel on the main branch.

On the stable branch a series of beta versions – identified by a lowercase b in their names – will be published, (e.g., 2.0.0b1, 2.0.0b2, etc.). This occurs every two weeks or so, as long as no serious errors are identified.

Following the beta phase, a stable version is released – for example, 2.0.0. Now that many more users are trying out the new release, further problems will be identified that were not noticed during the beta phase. These will be corrected by a series of patch releases (2.0.0p1, 2.0.0p2, etc.). The time intervals between these patches will initially be quite short (around a week), and later they will be much longer (a few months).

In addition to the master, daily builds are also published on the stable branch, which provide prompt bug fixes. These carry the name of the branch, plus the date, e.g., 2.0.0-2021.03.12.

You can use these versions in production, providing you observe the following:

When you display the version of a Checkmk site with the omd version command, you will see a further suffix, which the OMD views as a part of the version number:

This suffix enables the same versions of various Checkmk editions to be distinguished. This makes it possible to have, for example, version 2.0.0 of the Checkmk Raw Edition and the Checkmk Enterprise Standard Edition, installed simultaneously. This is in fact sometimes very sensible – namely if you wish to migrate from the CRE to the CEE. The following suffixes are possible:

We will actively maintain this stable version with patch releases. How long this happens depends on when the follow-up version is released and thus becomes the new stable version. The rule as of version 1.6.0 is: The active maintenance ends for a version 6 months after the release of the new version. Since for the stable version the follow-up version has not yet been released, the planned release date serves to determine the support periods.

This means that two versions are served in parallel with patch releases for 6 months: the stable version and the previous (oldstable) version. An overview of the support periods can be found at the end of this article.

After the end of the active maintenance, the stable branch moves to a passive maintenance phase, which generally lasts for another year.

During this time we generally only fix errors when commissioned by customers using support tickets through a support contract. If you have a contract with the break-fix option, such error fixes are covered.

Bug fixes during the passive maintenance phase generate further patch releases, which are of course also beneficial to users without a support contract.

Since daily builds and beta versions are only recommended for testing purposes and the support periods are correspondingly short, only the current and former stable versions are listed in the following table. Whether your version is still being maintained and when it has reached or will reach its end-of-life can be seen from the following table:

For older versions we highly recommend updating.