Versiones de Checkmk

En la rama de desarrollo (en el control de versiones de Git se denomina «master»), se está desarrollando el futuro de Checkmk. Para que los desarrolladores, usuarios y otras partes interesadas puedan hacerse una idea del estado actual del software en cualquier momento, cada día, entre las 0:00 y las 6:00, hora de Europa Central, se crea un paquete de instalación para todas las versiones de distribuciones Linux compatibles. Estos paquetes se denominan compilaciones diarias, instantáneas de Git o versiones de desarrollador, y representan el estado exacto del desarrollo del software al comienzo de cada día.

Las compilaciones diarias, como es lógico, suelen contener algunos errores, ya que son una instantánea más o menos «aleatoria» del estado actual del software. A diferencia de las versiones estables, las compilaciones diarias tampoco generan una nueva rama de desarrollo, por lo que no podemos aplicarles parches. La única forma de corregir un error en una compilación diaria es sustituirla por una compilación diaria más reciente, que puede tener sus propios problemas. Por esta razón, nunca se debe utilizar una compilación diaria en un entorno de producción.

No obstante, las compilaciones diarias son muy útiles si, como usuario, deseas probar nuevas funciones en tiempo real. ¡Esto es especialmente aplicable si tú mismo nos has encargado el desarrollo de la función!

Nuestro servicio de asistencia también estará encantado de ayudarte con cualquier dificultad relacionada con las compilaciones diarias, pero con las siguientes restricciones:

El lanzamiento de una nueva versión estable (por ejemplo, 2.4.0) comienza con una fase Beta. Para corregir todos los errores y preparar el software para su uso en producción, se creará una rama estable adicional que contenga únicamente correcciones de errores. El desarrollo de funciones para futuras versiones continúa en paralelo en la rama principal.

En la rama estable se publicarán una serie de versiones Beta —identificadas por «b» en minúsculas en sus nombres— (por ejemplo, 2.4.0b1, 2.4.0b2, etc.). Esto ocurre cada dos semanas aproximadamente, siempre que no se identifiquen errores graves.

Tras la fase Beta, se lanza una versión estable, también llamada versión principal, por ejemplo, 2.4.0. Ahora que muchos más usuarios están probando la nueva versión, se detectarán otros problemas que no se habían notado durante la fase Beta. Estos se corregirán mediante una serie de versiones de parche, a veces también llamadas patch releases (2.4.0p1, 2.4.0p2, etc.). Los intervalos de tiempo entre estas versiones de parche serán inicialmente bastante cortos (alrededor de una semana) y, más adelante, serán mucho más largos (unos meses).

Además del master, también se publican compilaciones diarias en la rama estable, que proporcionan Correcciones de errores inmediatas. Estas llevan el nombre de la rama, más la fecha, por ejemplo, 2.4.0-2025.03.30.

Puedes usar estas versiones en producción, siempre que respetes lo siguiente:

Mantendremos activamente esta versión estable con versiones de parche. La duración de este periodo depende de cuándo se lance la versión siguiente, que se convertirá así en la nueva versión estable. La regla a partir de la versión 1.6.0 es: El mantenimiento activo de una versión finaliza 6 meses después del lanzamiento de la nueva versión. Dado que para la versión estable aún no se ha lanzado la versión siguiente, la fecha de lanzamiento prevista sirve para determinar el ciclo de vida del producto.

Esto significa que durante 6 meses se ofrecen dos versiones en paralelo con versiones de parches: la versión estable y la versión anterior (oldstable). Al final de este artículo encontrarás una vista general del ciclo de vida del producto.

Una vez finalizado el mantenimiento activo, la rama estable pasa a una fase de mantenimiento pasivo, que suele durar un año más.

Durante este tiempo, por lo general solo corregimos errores cuando nos lo solicitan los clientes mediante tickets de soporte a través de un contrato de soporte.

Sin embargo, no hay garantía de que se solucione todo lo que los usuarios puedan considerar un error. Además, no todas las Correcciones de errores se aplicarán a las versiones más antiguas. Esto es especialmente cierto en el caso de las funciones que se consideran obsoletas: por lo general, estas no recibirán Correcciones de errores.

Las correcciones de errores durante la fase de mantenimiento pasivo generan nuevas versiones de parches, que, por supuesto, también benefician a los usuarios sin contrato de soporte.

En la siguiente tabla puedes ver si tu versión sigue recibiendo mantenimiento y cuándo ha llegado o llegará al fin de vida útil:

Si tienes una versión anterior, te recomendamos encarecidamente que la actualices.