1. The development cycle
The cycle from one stable version of Checkmk to the next takes around twelve to eighteen months.
It begins following the release of the preceding version – for example
– with the start of development of the new features for the coming version –
2.0.0. This development takes place on the main development
After about six to nine months the first innovation version will be created. This will be maintained for a short time in its own branch.
Following the creation of two to four innovation versions the beta phase commences – for which a branch will also be split off on which the new stable version will be finalized and later maintained. On the main branch the preparation for the next cycle will then begin.
As well as on the main development branch, daily intermediate versions (daily builds) are also created on the stable branch – which offer access to new features or bug fixes. An graphic representation of the whole process for the 1.6.0 version looks somewhat like the illustration below:
2. Versions and editions
2.1. Daily builds from the master
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:
We can only help if the daily build is no more than a week old.
We cannot create patches.
Daily builds are not covered by break-fix support.
2.2. Innovation versions
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.,
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
Innovation versions are not covered by break-fix support.
2.3. Beta versions
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.0b2, etc.). This occurs every two weeks or so, as long as no
serious errors are identified.
2.4. Stable version
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.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.,
You can use these versions in production, providing you observe the following:
Only use a daily build on the stable branch if it solves a serious problem.
Update to the next patch version as soon as it becomes available.
2.5. Editions and their identifying suffixes
When you display the version of a Checkmk site with the
command, you will see a further suffix, which the OMD views as
a part of the version number:
OMD[mysite]:~$ omd version OMD - Open Monitoring Distribution Version 2.0.0.cre
This suffix enables the same versions of various Checkmk editions to be
distinguished. This makes it possible to have, for example, version
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:
Checkmk Raw Edition
Checkmk Enterprise Free Edition
Checkmk Enterprise Standard Edition
Checkmk Enterprise Managed Services Edition
3. Maintenance and support
3.1. Active maintenance
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.
3.2. Passive maintenance
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.
3.3. Support after maintenance
Once the passive maintenance phase has run its course no further releases will be produced. Customers who are dependent on such an older version and who also have a support contract can still receive support from us. Possible problems can however only be corrected by modifying data on the customer’s system. This is of course very time consuming and consequently more expensive. In addition, such actions are not covered by break-fix support.
3.4. Support periods of the stable versions
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:
|Version||Release date||End of active maintenance||End of passive maintenance|
6 months after release of v2.1.0