Versions de Checkmk

C'est sur la branche de développement (appelée « master » dans le système de contrôle de version Git) que se construit l'avenir de Checkmk. Afin que les développeurs, les utilisateurs et les autres parties intéressées puissent à tout moment se faire une idée de l’état actuel du logiciel, un paquet d’installation pour toutes les versions de distributions Linux prises en charge est créé chaque jour entre 0 h 00 et 6 h 00, heure d’Europe centrale. Ces paquets sont appelés « versions journalières », « snapshots » ou « versions de développement », et ils représentent l’état exact du développement du logiciel au début de chaque journée.

Les versions journalières contiennent naturellement souvent des bogues, car elles constituent un snapshot plus ou moins « aléatoire » de l’état actuel du logiciel. Contrairement aux versions stables, les versions journalières ne génèrent pas non plus de nouvelle branche de développement et ne peuvent donc pas être corrigées par nos soins. La seule façon de corriger une erreur dans une version journalière est de la remplacer par une version journalière plus récente, qui peut toutefois présenter ses propres problèmes. C'est pourquoi une version journalière ne doit jamais être utilisée dans un environnement de production.

Néanmoins, les versions journalières sont très utiles si, en tant qu’utilisateur, vous souhaitez tester de nouvelles fonctionnalités en temps réel. Cela vaut tout particulièrement si vous nous avez vous-même chargés de développer cette fonctionnalité !

Notre service d'assistance se fera également un plaisir de vous aider en cas de difficultés avec les versions journalières, mais sous réserve des restrictions suivantes :

La publication d'une nouvelle version stable (par exemple 2.4.0) commence par une phase de développement bêta. Afin de corriger toutes les erreurs et de rendre le logiciel prêt pour la production, une branche stable supplémentaire contenant uniquement des corrections d'erreurs sera créée. Le développement des fonctionnalités pour les versions futures se poursuit en parallèle sur la branche principale.

Sur la branche stable, une série de versions bêta – identifiées par un « b » en minuscules dans leur nom – sera publiée (par exemple, 2.4.0b1, 2.4.0b2, etc.). Cela se produit toutes les deux semaines environ, tant qu’aucune erreur grave n’est identifiée.

À l'issue de la phase de développement bêta, une version stable, également appelée version majeure, est publiée – par exemple, 2.4.0. À présent que de nombreux utilisateurs testent la nouvelle version, d’autres problèmes qui n’avaient pas été détectés pendant la phase de développement bêta seront identifiés. Ceux-ci seront corrigés par une série de versions de correctifs, parfois également appelées versions de patch (2.4.0p1, 2.4.0p2, etc.). Les intervalles de temps entre ces versions de correctifs seront initialement assez courts (environ une semaine), puis ils s’allongeront considérablement (quelques mois).

En plus de la branche master, des versions journalières sont également publiées sur la branche stable, qui fournissent des corrections de bugs rapides. Celles-ci portent le nom de la branche, suivi de la date, par exemple 2.4.0-2025.03.30.

Vous pouvez utiliser ces versions en production, à condition de respecter les consignes suivantes :

Nous assurerons activement la maintenance de cette version stable à l'aide de versions de correctifs. La durée de cette période dépend de la date de sortie de la version suivante, qui deviendra alors la nouvelle version stable. La règle applicable à partir de la version 1.6.0 est la suivante : La maintenance active d'une version prend fin six mois après la sortie de la nouvelle version. Étant donné que, pour la version stable, la version suivante n'a pas encore été publiée, la date de sortie prévue sert à déterminer le cycle de vie du produit.

Cela signifie que deux versions sont prises en charge en parallèle avec des versions de correctifs pendant 6 mois : la version stable et la version précédente (oldstable). Vous trouverez un aperçu du cycle de vie du produit à la fin de cet article.

À l'issue de la maintenance active, la branche stable passe à une phase de maintenance passive, qui dure généralement encore un an.

Pendant cette période, nous ne corrigeons généralement les erreurs que sur demande des clients, via des tickets d'assistance dans le cadre d'un contrat d'assistance.

Cependant, rien ne garantit que tout ce que les utilisateurs pourraient considérer comme un bug sera corrigé. De plus, toutes les corrections de bugs ne seront pas portées sur les versions les plus anciennes. Cela vaut tout particulièrement pour les fonctionnalités considérées comme obsolètes — celles-ci ne bénéficieront généralement pas de corrections de bugs.

Les corrections de bugs effectuées pendant la phase de maintenance passive donnent lieu à de nouvelles versions de correctifs, qui profitent bien sûr également aux utilisateurs ne disposant pas d’un contrat d’assistance.

Le tableau suivant vous indique si votre version est toujours maintenue et à quelle date elle a atteint ou atteindra sa fin de vie :

Pour les versions plus anciennes, nous vous recommandons vivement de procéder à une mise à jour.