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 commercial editions and give you the possibility to use new and interesting features in the software long before the next stable version is released. They represent a compromise between stability and new features. However, innovation versions are optional and are not provided in preparation for each stable version.

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., 2.0.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., 2.0.0i2p1.

The release of a new stable version, (e.g. 2.2.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.2.0b1, 2.2.0b2, etc.). This occurs every two weeks or so, as long as no serious errors are identified.

Following the beta phase, a stable version, also called major version, is released – for example, 2.2.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 versions, sometimes also called patch releases (2.2.0p1, 2.2.0p2, etc.). The time intervals between these patch versions 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.2.0-2023.03.30.

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

We will actively maintain this stable version with patch versions. 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 product lifecycle.

This means that two versions are served in parallel with patch versions for 6 months: the stable version and the previous (oldstable) version. An overview of the product lifecycle 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.

Bug fixes during the passive maintenance phase generate further patch versions, 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 product lifecycle is 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.