Modelo de lanzamiento

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

Matriz de compatibilidad

Todas las versiones de LTS de Bazel se pueden encontrar en la página de lanzamientos de 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 retrocompatibles con la versión anterior. Cada versión principal de Bazel es una versión de LTS.
• Una versión secundaria contiene correcciones de errores retrocompatibles 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, un nuevo lanzamiento 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 lanzamientos continuos desde HEAD.
• Activa: 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 compatibilidad con 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 lanzamiento.

Lanzamientos continuos

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

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 inmediatamente a la etapa Activa, y la versión de LTS anterior ingresa a la etapa Mantenimiento.
• Versión secundaria: Se espera que las nuevas versiones secundarias en el segmento de LTS activo se lancen una vez cada 2 meses.
• Versión de parche: Se espera que las nuevas versiones de parche para las versiones de LTS en las etapas Activa y Mantenimiento se lancen 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 de Mantenimiento durante 2 años.

Para los lanzamientos planificados, consulta nuestros problemas de lanzamiento en GitHub.

Procedimiento y políticas de lanzamiento

Para los lanzamientos continuos, el proceso es sencillo: aproximadamente cada dos semanas, se crea un lanzamiento nuevo, que se alinea con la misma línea de base que el lanzamiento interno de Google Blaze. Debido al cronograma de lanzamiento rápido, no transferimos ningún cambio a los lanzamientos continuos.

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

1. Determina una confirmación de línea de base para el lanzamiento.
   • Para un nuevo lanzamiento de LTS principal, la confirmación de línea de base es el HEAD de la rama principal.
   • Para un lanzamiento secundario o de parche, la confirmación de línea de base es el HEAD de la versión más reciente actual del mismo lanzamiento de LTS.
2. Crea una rama de lanzamiento 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 lanzamiento.
   • La comunidad puede sugerir que se transfieran ciertas confirmaciones respondiendo "@bazel-io flag" en los problemas o las RP pertinentes de GitHub para marcarlos como posibles bloqueadores de lanzamiento. El equipo de Bazel los clasifica y decide si transferir las confirmaciones.
   • Solo se pueden transferir las confirmaciones retrocompatibles 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 lanzamiento. 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 lanzamiento 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, 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 lanzamiento. Para obtener un ejemplo visual de una solicitud de cherry-pick completada, consulta este ejemplo .

5. Identifica los bloqueadores de lanzamiento y corrige los problemas que se encuentran en la rama de lanzamiento.

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

6. Crea un nuevo candidato para el lanzamiento desde la rama de lanzamiento cuando se resuelvan todos los bloqueadores de lanzamiento 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 lanzamiento, 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 lanzamiento después de crear el primer candidato para el lanzamiento. Las selecciones se limitan solo a 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 el lanzamiento oficial si no se encuentran más bloqueadores de lanzamiento.

   • Para los lanzamientos de parches, envía el lanzamiento al menos dos días hábiles después de que se lance el último candidato para el lanzamiento.
   • Para los lanzamientos principales y secundarios, envía el lanzamiento dos días hábiles después de que se lance el último candidato para el lanzamiento, pero no antes de una semana después de que se lance el primer candidato para el lanzamiento.
   • El lanzamiento solo se envía en un día en el que el día siguiente es un día hábil.
   • El lanzamiento se anuncia en bazel-discuss, el equipo de Bazel supervisa y aborda los informes de errores de la comunidad para el nuevo lanzamiento.

Cómo informar regresiones

Si un usuario encuentra una regresión en un nuevo lanzamiento de Bazel, un candidato para el lanzamiento o incluso Bazel en HEAD, envía un error en GitHub. Puedes usar Bazelisk para seccionar la confirmación culpable y agregar esta información al 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 realizar la sección 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 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 sección de Bazelisk bisect.

Recuerda actualizar Bazelisk a la versión más reciente para usar la función de secció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.