Checkmk-Versionen

Auf dem Entwicklungszweig (in der Versionskontrolle Git heißt dieser „master“) wird die Zukunft von Checkmk entwickelt. Damit Entwickler, Anwender und andere Interessierte sich jederzeit ein Bild vom aktuellen Stand der Software machen können, wird jeden Tag zwischen 0:00 und 6:00 Uhr mitteleuropäischer Zeit ein Installationspaket für alle unterstützten Linux-Distributionen gebaut. Diese Pakete werden auch Daily Builds, Git Snapshots oder Entwicklerversionen genannt und stellen den exakten Stand der Softwareentwicklung zu Beginn eines jeden Tages dar.

Die Tagesversionen sind natürlich oft fehlerbehaftet, da sie quasi einen mehr oder weniger „zufälligen“ Stand der Software enthalten. Im Gegensatz zu Innovation- und stabilen Versionen eröffnen Tagesversionen auch keinen neuen Entwicklungszweig und können daher auch nicht von uns gepatcht werden. Die einzige Möglichkeit einen Fehler in einer Tagesversion zu beheben, ist das Einspielen einer neueren Tagesversion, bei der dieser Fehler behoben ist. Leider kann dabei natürlich wieder ein neuer, anderer Fehler hineingeraten. Daher sollten Sie Tagesversionen niemals produktiv einsetzen.

Trotzdem sind die Tagesversionen sehr nützlich, wenn Sie neue Features zeitnah ausprobieren möchten. Dies gilt insbesondere dann, wenn Sie diese Features selbst bei uns in Auftrag gegeben haben!

Unser Support hilft Ihnen auch gerne bei Schwierigkeiten mit Tagesversionen, allerdings mit folgenden Einschränkungen:

Innovation-Versionen sind ein besonderes Feature der Checkmk Enterprise Editions und geben Ihnen die Möglichkeit, neue interessante Features der Software bereits lange vor der nächsten stabilen Version zu nutzen. Sie stellen einen Kompromiss zwischen Stabilität und Innovation dar.

Die erste Innovation-Version gibt es in der Regel ein halbes Jahr nach dem letzten stabilen Release. In einer Abfolge von 1-2 Monaten erscheinen 3-4 Releases, welche jeweils mit dem Kürzel i nummeriert sind (z.B. 1.6.0i2). Ähnlich wie stabile Versionen werden auch diese aktiv gepflegt  —  allerdings nur eine begrenzte Zeit von 1-2 Monaten, an die sich eine ebenso lange passive Pflege anschließt. Patches von i-Versionen erkennen Sie an einem p-Suffix, z.B. 1.6.0i2p1.

Innovation-Versionen sind nicht vom Break/Fix Support abgedeckt.

Das Release einer neuen stabilen Version (z.B. 2.0.0) beginnt mit einer Beta-Phase. Um alle Fehler zu beheben und die Software tauglich für die Produktion zu machen, wird dazu ein stabiler Zweig abgespalten, welcher nur noch Fehlerbehebungen enthält. Auf dem Hauptzweig geht parallel die Entwicklung der Features für die Zukunft weiter.

Auf dem stabilen Zweig wird nun eine Serie von Beta-Versionen mit einem kleinen b im Namen veröffentlicht — (z.B. 2.0.0b1, 2.0.0b2, usw.). Das geschieht etwa alle zwei Wochen  —  solange bis keine gravierenden Fehler mehr bekannt sind.

Nach der Beta-Phase gibt es den feierlichen Augenblick, an dem die neue stabile Version erscheint (z.B. 2.0.0). Da die Software nun von mehr Benutzern eingesetzt wird, werden jetzt in der Regel noch Probleme bekannt, die während der Beta-Phase nicht aufgefallen sind. Diese werden in einer Reihe von Patch Releases behoben (2.0.0p1, 2.0.0p2, usw.). Die Abstände dieser Releases sind anfangs recht kurz (etwa eine Woche) und später viel länger (einige Monate).

Zusätzlich zum Master werden auch auf dem stabilen Zweig Tagesversionen veröffentlicht, die Ihnen Bugfixes zeitnah bereitstellen. Diese tragen den Namen des Zweigs plus das Datum, z.B. 2.0.0-2021.03.12.

Sie können diese Versionen produktiv einsetzen, solange Sie Folgendes beachten:

Wenn Sie die Version einer Checkmk-Instanz mit dem Befehl omd version anzeigen, sehen Sie noch einen Suffix, der aus Sicht von OMD Teil der Versionsnummer ist:

Dieses Suffix dient dazu, gleiche Versionen von verschiedenen Checkmk-Editionen zu unterscheiden. Auf diese Art ist es kein Problem, z.B. gleichzeitig die Version 2.0.0 der Checkmk Raw Edition und der Checkmk Enterprise Standard Edition installiert zu haben. Dies ist manchmal sogar sehr sinnvoll  —  nämlich wenn Sie von der CRE auf die CEE umsteigen möchten. Folgende Suffixe sind möglich:

Die stabile Version wird aktiv gepflegt, d.h. mit Patch Releases versorgt. Wie lange das passiert, hängt davon ab, wann die Folgeversion freigegeben wird und dadurch zur neuen stabilen Version wird. Die Regel ab der Version 1.6.0 lautet: Die aktive Pflege endet für eine Version 6 Monate nach Freigabe der neuen Version. Da für die stabile Version die Folgeversion noch nicht freigegeben ist, dient der geplante Freigabetermin zur Festlegung der Support-Zeiträume.

Damit werden für 6 Monate zwei Versionen parallel mit Patch Releases bedient: die stabile Version (stable) und die Vorgängerversion (oldstable). Eine Übersicht der Support-Zeiträume finden Sie am Ende dieses Artikels.

Nach Ablauf der aktiven Pflege geht der stabile Zweig in die passive Pflege über, die in der Regel ein weiteres Jahr dauert.

Während dieser Zeit beheben wir Fehler nur noch im Auftrag von Kunden, die uns diese im Rahmen eines Support-Vertrags in Form von Support Tickets melden. Falls Sie einen Vertrag mit Break/Fix-Option haben, sind solche Fehlerbehebungen darin enthalten.

Bugfixes während der passiven Pflege lösen weitere Patch Releases aus, von denen dann natürlich auch diejenigen Anwender profitieren, welche keinen Supportvertrag haben.

Da Tages- und Beta-Versionen nur zu Testzwecken zu empfehlen und dafür auch die Support-Zeiträume entsprechend kurz sind, enthält die folgende Tabelle nur die aktuellen und ehemaligen stabilen Versionen. Ob Ihre Version also noch gepflegt wird und wann sie ihr Lebensende (End of Life) erreicht hat oder erreichen wird, können Sie der nachfolgenden Tabelle entnehmen:

Für ältere Versionen empfehlen wir dringend ein Update.