Check_MK Versions


1. The development cycle

The cycle from one stable version of Check_MK to the next takes around eighteen months. It begins following the release of the preceeding version – for example 1.2.8 – with the start of development of the new features for the coming version – for example 1.4.0. This development takes place on the main development branch (master).

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 finalised 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 (GIT-Snapshots) are also created on the stable branch – which offer access to new features or bug fixes. An graphic representation of the whole process looks somewhat like the illustration below:

2. The various versions in detail

2.1. Daily builds from the master

On the development branch (in the GIT's version control this is referred to as ‘the master’), Check_MK'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 versions 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 stable and Innovation 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 version 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 versions, but under the following restrictions:

  • We can only help if the daily version is no more than a week old.
  • We cannot create patches.
  • Daily versions are not covered by Break/Fix-Support.

2.2. The beta phase

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

2.3. Active maintenance of the stable version

Following the beta phase, a stable version is released – for example, 1.4.0. Once deployment of the now stable branch has begun and a wider spectrum of users try out the new release, further issues will be identified. These will be corrected by a series of patch releases (1.4.0p1, 1.4.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). We will actively maintain this stable branch with patch releases for about eighteen months.

Daily versions of the stable branch, which provide prompt bug fixes, will also be published. These carry the name of the branch, plus the date, e.g., 1.4.0-2017.04.08.

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

  • Only use a stable daily version if it solves a serious problem.
  • Update to the next patch version as soon as it becomes available.

2.4. Passive maintenance

After the active maintenance period, the stable branch moves to a passive maintenance phase, which generally exists for about a further eighteen months. 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.

2.5. Subsequent support

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.

2.6. Innovation-Versions

Innovation-Versions are a special feature of the  Check_MK Enterprise Edition 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.4.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 recognised by a p-suffix, e.g., 1.4.0i2p1.

Innovation-Versions are not covered by Break/Fix-Support.

2.7. The editions and their identifying suffixes

When you display the version of a Check_MK-instance with the omd version 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 1.4.0p2.cre

This suffix enables the same versions of various Check_MK-Editions to be distinguished. This makes it possible to have, for example, version 1.4.0p2 of the Check_MK Raw Edition and the Check_MK Enterprise 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:

.cre  Check_MK Raw Edition
.cee  Check_MK Enterprise Edition
.demo Demo version of the  Check_MK Enterprise Edition
.cme Check_MK Managed Services Edition (from mid-2017)