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 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:
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:
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 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.
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: