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 kommerziellen Editionen 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. Innovation-Versionen sind jedoch optional und werden nicht in Vorbereitung auf jede stabile Version bereitgestellt.

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. 2.0.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. 2.0.0i2p1.

Das Release einer neuen stabilen Version (z.B. 2.3.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.3.0b1, 2.3.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, auch Major-Version genannt, erscheint (z.B. 2.3.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-Versionen, manchmal auch als Patch Releases bezeichnet, behoben (2.3.0p1, 2.3.0p2, usw.). Die Abstände dieser Patch-Versionen 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 Bug Fixes zeitnah bereitstellen. Diese tragen den Namen des Zweigs plus das Datum, z.B. 2.3.0-2024.03.30.

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

Die stabile Version wird aktiv gepflegt, d.h. mit Patch-Versionen 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 des Produkt-Lifecycle.

Damit werden für 6 Monate zwei Versionen parallel mit Patch-Versionen bedient: die stabile Version (stable) und die Vorgängerversion (oldstable). Eine Übersicht über den Produkt-Lifecycle 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.

Bug Fixes während der passiven Pflege lösen weitere Patch-Versionen aus, von denen dann natürlich auch diejenigen Anwender profitieren, welche keinen Support-Vertrag haben.

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.