Modelo de lanzamiento

Como se anunció en la entrada de blog original, Bazel 4.0 y versiones posteriores proporcionan compatibilidad con dos segmentos de versiones: versiones continuas y versiones de asistencia a largo plazo (LTS). En esta página, se incluye la información más reciente sobre el modelo de versiones de Bazel.

Matriz de compatibilidad

Todas las versiones de LTS de Bazel se pueden encontrar en la página de versiones en GitHub.

Control de versiones de actualización

Bazel usa un esquema de control de versiones Semántico major.minor.patch.

• Una versión principal contiene funciones que no son compatibles con versiones anteriores. Cada versión principal de Bazel es una versión de LTS.
• Una versión secundaria contiene correcciones de errores compatibles con versiones anteriores y funciones transferidas desde la rama principal.
• Una versión de parche contiene correcciones de errores críticos.

Además, las versiones previas al lanzamiento se indican agregando un guion y un sufijo de fecha al siguiente número de versión principal.

Por ejemplo, una versión nueva de cada tipo daría como resultado los siguientes números de versión:

• Principal: 6.0.0
• Secundaria: 6.1.0
• Parche: 6.1.2
• Antes del lanzamiento: 7.0.0-pre.20230502.1

Etapas de compatibilidad

Para cada versión principal de Bazel, hay cuatro etapas de compatibilidad:

• Continuo: Esta versión principal aún está en la etapa previa al lanzamiento. El equipo de Bazel publica versiones continuas desde HEAD.
• Activo: Esta versión principal es la versión de LTS activa actual. El equipo de Bazel transfiere funciones importantes y correcciones de errores a sus versiones secundarias.
• Mantenimiento: Esta versión principal es una versión de LTS antigua en modo de mantenimiento. El equipo de Bazel solo promete transferir correcciones de errores críticos para problemas de seguridad y problemas de compatibilidad con el SO a esta versión de LTS.
• Obsoleto: El equipo de Bazel ya no proporciona asistencia para esta versión principal . Todos los usuarios deben migrar a versiones de LTS de Bazel más recientes.

Frecuencia de actualización

Bazel publica versiones periódicamente para dos segmentos de versiones.

Versiones continuas

• Las versiones continuas se coordinan con la versión de Google Blaze y se lanzan desde HEAD cada dos semanas. Es una vista previa de la próxima versión de LTS de Bazel.
• Las versiones continuas pueden enviar cambios incompatibles. Se recomiendan marcas incompatibles para los cambios rotundos principales. El lanzamiento de cambios incompatibles debe seguir nuestra política de compatibilidad con versiones anteriores.

Versiones de LTS

• Versión principal: Se espera que se corte una nueva versión de LTS de HEAD aproximadamente cada 12 meses. Una vez que se lanza una nueva versión de LTS, ingresa de inmediato a la etapa Activa y la versión de LTS anterior ingresa a la etapa Mantenimiento.
• Versión secundaria: Se espera que se lancen nuevas versiones secundarias en el segmento de LTS activo una vez cada 2 meses.
• Versión de parche: Se espera que se lancen nuevas versiones de parche para las versiones de LTS en las etapas Activa y Mantenimiento a pedido para correcciones de errores críticos.
• Una versión de LTS de Bazel ingresa a la etapa Obsoleto después de estar en la etapa Mantenimiento durante 2 años.

Para las versiones planificadas, consulta nuestros problemas de versiones en GitHub.

Procedimiento y políticas de versiones

Para las versiones continuas, el proceso es sencillo: cada dos semanas, aproximadamente, se crea una versión nueva, que se alinea con la misma línea de base que la versión interna de Google Blaze. Debido al programa de versiones rápidas, no transferimos ningún cambio a las versiones continuas.

Para las versiones de LTS, se siguen los siguientes procedimientos y políticas:

1. Determina una confirmación de línea de base para la versión.
   • Para una nueva versión principal de LTS, la confirmación de línea de base es el HEAD de la rama principal.
   • Para una versión secundaria o de parche, la confirmación de línea de base es el HEAD de la versión más reciente actual de la misma versión de LTS.
2. Crea una rama de versión con el nombre release-<version> a partir de la confirmación de línea de base.
3. Transfiere los cambios a través de las RP a la rama de versión.
   • La comunidad puede sugerir que se transfieran ciertas confirmaciones respondiendo "@bazel-io flag" en los problemas o las RP de GitHub pertinentes para marcarlos como posibles bloqueadores de versiones. El equipo de Bazel los clasifica y decide si transferir las confirmaciones.
   • Solo se pueden transferir las confirmaciones compatibles con versiones anteriores en la rama principal, se aceptan cambios secundarios adicionales para resolver conflictos de combinación.

4. Transfiere los cambios con el problema de solicitud de Cherry-Pick para los mantenedores de Bazel.

   • Los mantenedores de Bazel pueden solicitar que se elijan confirmaciones específicas para una rama de versión. Este proceso se inicia creando una solicitud de cherry-pick en GitHub. Te mostramos cómo.

     1. Abre la solicitud de cherry-pick.
     2. Completa los detalles de la solicitud.
        • Título: Proporciona un título conciso y descriptivo para la solicitud.
        • IDs de confirmación: Ingresa los IDs de las confirmaciones que deseas elegir. Si hay varias confirmaciones, sepáralas con comas.
        • Categoría: Especifica la categoría de la solicitud.
        • Revisores: Para varios revisores, separa sus IDs de GitHub con comas.
     3. Establece el hito.
        • Busca la sección "Hito" y haz clic en la configuración.
        • Selecciona los bloqueadores de versiones X.Y.Z adecuados. Esta acción activa el bot de cherry-pick para procesar tu solicitud de la rama "release-X.Y.Z".
     4. Envía el problema.
        • Una vez que se completen todos los detalles y se establezca el hito, envía el problema.

   • El bot de cherry-pick procesará la solicitud y notificará si las confirmaciones son aptas para la selección. Si las confirmaciones se pueden elegir, lo que significa que no hay conflicto de combinación mientras se elige la confirmación, entonces el bot creará una solicitud de extracción nueva. Cuando un miembro del equipo de Bazel aprueba la solicitud de extracción, las confirmaciones se eligen y se combinan con la rama de versión. Para ver un ejemplo visual de una solicitud de cherry-pick completada, consulta este ejemplo .

5. Identifica los bloqueadores de versiones y corrige los problemas que se encuentran en la rama de versión.

   • La rama de versión se prueba con el mismo conjunto de pruebas en postsubmit y descendentes en Bazel CI. El equipo de Bazel supervisa los resultados de las pruebas de la rama de versión y corrige las regresiones que se encuentran.

6. Crea un nuevo candidato para el lanzamiento desde la rama de versión cuando se resuelvan todos los bloqueadores de versiones conocidos.

   • El candidato para el lanzamiento se anuncia en bazel-discuss, el equipo de Bazel supervisa los informes de errores de la comunidad para el candidato.
   • Si se identifican nuevos bloqueadores de versiones, vuelve al último paso y crea un nuevo candidato para el lanzamiento después de resolver todos los problemas.
   • No se permite agregar funciones nuevas a la rama de versión después de crear el primer candidato para el lanzamiento. Las selecciones se limitan solo a las correcciones críticas. Si se necesita una selección, el solicitante debe responder las siguientes preguntas: ¿Por qué es fundamental este cambio y qué beneficios proporciona? ¿Cuál es la probabilidad de que este cambio introduzca una regresión?

7. Envía el candidato para el lanzamiento como la versión oficial si no se encuentran más bloqueadores de versiones .

   • Para las versiones de parche, envía la versión al menos dos días hábiles después de que se publique el último candidato para el lanzamiento.
   • Para las versiones principales y secundarias, envía la versión dos días hábiles después de que se publique el último candidato para el lanzamiento, pero no antes de una semana después de que se publique el primer candidato para el lanzamiento.
   • La versión solo se envía en un día en el que el día siguiente es un día hábil.
   • La versión se anuncia en bazel-discuss, el equipo de Bazel supervisa y aborda los informes de errores de la comunidad para la nueva versión.

Cómo informar regresiones

Si un usuario encuentra una regresión en una nueva versión de Bazel, un candidato para el lanzamiento o incluso Bazel en HEAD, envía un error en GitHub. Puedes usar Bazelisk para dividir la confirmación culpable y, luego, incluir esta información en el informe de errores.

Por ejemplo, si tu compilación se realiza correctamente con Bazel 6.1.0, pero falla con el segundo candidato para el lanzamiento de 6.2.0, puedes dividirla a través de

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

Puedes establecer la variable de entorno BAZELISK_SHUTDOWN o BAZELISK_CLEAN para ejecutar los comandos de bazel correspondientes y restablecer el estado de la compilación si es necesario para reproducir el problema. Para obtener más detalles, consulta la documentación sobre la función de división de Bazelisk bisect.

Recuerda actualizar Bazelisk a la versión más reciente para usar la función de división.

Compatibilidad de reglas

Si eres autor de reglas y deseas mantener la compatibilidad con diferentes versiones de Bazel, consulta la página Compatibilidad de reglas.