Last updated: April 28. 2017
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 possibility for correcting an error in a daily build is to install a newer daily version in which the error has been corrected. Unfortunately, this newer version can of course contain a newer, diffent error. 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:
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 comes the solemn moment when the new stable version is released – for example, 1.4.0. Because the software will now be put into service by a wider spectrum of users, problems that had not been noticeable during the beta phase will generally now 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:
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.
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.
Innovation-Versions are a special feature of the
As a rule the first Innovation-Version becomes available about half a year after the last stable release. Over the succeeding 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.
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. In this way it is no problem, for example, to have version
1.4.0p2 of the