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 en cualquier momento del estado actual del software, cada día entre las 0:00 y las 6:00, hora de Europa Central, se creará un paquete de instalación para todas las versiones de distribución de 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.

Naturalmente, las compilaciones diarias contendrán a menudo algunos errores, ya que contienen una instantánea más o menos "aleatoria" del estado actual del software. A diferencia de las versiones de innovación y estable, las compilaciones diarias tampoco generan una nueva rama de desarrollo, por lo que no pueden ser parcheadas por nosotros. 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, una compilación diaria nunca debe utilizarse para un entorno de producción.

Sin embargo, las compilaciones diarias son muy útiles si tú, como usuario, quieres probar nuevas funciones en tiempo real, ¡especialmente si tú mismo nos has encargado el desarrollo de la función!

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

Las versiones de innovación son una característica especial de las ediciones comerciales y te dan la posibilidad de utilizar funciones nuevas e interesantes del software mucho antes de que se publique la siguiente versión estable. Representan un compromiso entre estabilidad y nuevas funciones. Sin embargo, las versiones de innovación son opcionales y no se proporcionan como preparación para cada versión estable.

Por regla general, la primera versión de innovación estará disponible aproximadamente medio año después de la última versión estable. Durante los 1-2 meses siguientes, se producirán 3-4 releases, cada una identificada en secuencia por un número i (por ejemplo, 2.0.0i2). Al igual que las versiones estables, éstas también se mantendrán activamente, pero sólo durante un tiempo limitado de alrededor de 1-2 meses, al que seguirá un periodo similar de mantenimiento pasivo. Los parches de las versiones i pueden reconocerse por un sufijo p, por ejemplo, 2.0.0i2p1.

El lanzamiento de una nueva versión estable, (por ejemplo, 2.3.0), comienza con una fase Beta. Para corregir todos los errores, y para que el software esté listo para la producción, se separará una rama estable adicional que sólo contendrá correcciones de errores. El desarrollo de características 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 una b minúscula en sus nombres- (por ejemplo, 2.3.0b1, 2.3.0b2, etc.) Esto ocurre cada dos semanas aproximadamente, siempre que no se identifiquen errores graves.

Tras la fase Beta, se publica una versión estable, también llamada major release- por ejemplo, 2.3.0. Ahora que muchos más usuarios están probando la nueva versión, se identificarán más problemas que no se detectaron durante la fase Beta. Éstos se corregirán mediante una serie de versiones de parche, a veces también llamadas patch release (2.3.0p1, 2.3.0p2, etc.) Los intervalos de tiempo entre estas versiones de parche serán inicialmente bastante cortos (alrededor de una semana), y más tarde serán mucho más largos (unos meses).

Además de la master, también se publican compilaciones diarias en la rama estable, que proporcionan correcciones de errores puntuales. Éstas llevan el nombre de la rama, más la fecha, por ejemplo, 2.3.0-2025.03.30.

Puedes utilizar estas versiones en producción, siempre que observes lo siguiente:

Mantendremos activamente esta versión estable con versiones de parche. El tiempo durante el que esto ocurra dependerá de cuándo se publique la versión de seguimiento y se convierta así en la nueva versión estable. La regla a partir de la versión 1.6.0 es: el mantenimiento activo finaliza para una versión 6 meses después de la publicación de la nueva versión. Como para la versión estable aún no se ha publicado la versión de seguimiento, la fecha de publicación prevista sirve para determinar el ciclo de vida del producto.

Esto significa que se sirven dos versiones en paralelo con versiones de parche durante 6 meses: 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, generalmente sólo corregimos errores cuando nos lo encargan los clientes mediante tickets de soporte a través de un contrato de soporte.

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

En la siguiente tabla puedes ver si tu versión sigue siendo mantenida y cuándo ha alcanzado o alcanzará el fin de vida útil:

Para versiones anteriores, recomendamos encarecidamente la actualización.