Como se anunció en la entrada de blog original, Bazel 4.0 y las versiones posteriores proporcionan compatibilidad con dos segmentos: 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 lanzamiento de Bazel.
Matriz de compatibilidad
| Versión de LTS | Etapa de compatibilidad | Última versión | Fin de la compatibilidad |
|---|---|---|---|
| Bazel 10 | Continuo | Consulta la página de lanzamientos progresivos | N/A |
| Bazel 9 | Activo | 9.3.1 | Diciembre de 2028 |
| Bazel 8 | Mantenimiento | 8.8.2 | Diciembre de 2027 |
| Bazel 7 | Mantenimiento | 7.7.2 | Dic de 2026 |
| Bazel 6 | Obsoleto | 6.6.0 | Diciembre de 2025 |
| Bazel 5 | Obsoleto | 5.4.1 | Enero de 2025 |
| Bazel 4 | Obsoleto | 4.2.4 | enero de 2024 |
Todas las versiones de LTS de Bazel se pueden encontrar en la página de versiones en GitHub. La insignia "Latest" en GitHub siempre apunta a la versión semántica más alta, incluso si se lanza un parche de mantenimiento para una versión anterior más recientemente.
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 LTS.
- Una versión secundaria contiene correcciones de errores y funciones retrocompatibles que se trasladaron desde la rama principal.
- Una versión de parche contiene correcciones de errores críticos.
Además, las versiones preliminares se indican agregando un guion y un sufijo de fecha al siguiente número de versión principal.
Por ejemplo, una nueva versión de cada tipo daría como resultado estos números de versión:
- Versión principal: 6.0.0
- Menor: 6.1.0
- Parche: 6.1.2
- Versión previa al lanzamiento: 7.0.0-pre.20230502.1
Etapas de asistencia
Para cada versión principal de Bazel, hay cuatro etapas de asistencia:
- Continuo: Esta versión principal aún se encuentra en fase previa al lanzamiento, y el equipo de Bazel publica versiones continuas desde HEAD.
- Activa: Esta versión principal es la versión LTS activa actual. El equipo de Bazel realiza retrocompatibilidad de funciones importantes y correcciones de errores en sus versiones secundarias.
- Mantenimiento: Esta versión principal es una versión LTS antigua en modo de mantenimiento. El equipo de Bazel solo promete realizar correcciones de errores críticos para problemas de seguridad y de compatibilidad con el SO en esta versión LTS.
- Obsoleta: El equipo de Bazel ya no proporciona asistencia para esta versión principal. Todos los usuarios deben migrar a versiones más recientes de Bazel LTS.
Frecuencia de actualización
Bazel publica periódicamente versiones para dos segmentos.
Lanzamientos progresivos
- Las versiones continuas se coordinan con la versión de Google Blaze y se lanzan desde HEAD aproximadamente cada dos semanas. Es una versión preliminar de la próxima versión de LTS de Bazel.
- Las versiones continuas pueden incluir cambios incompatibles. Se recomiendan las marcas incompatibles para los cambios rotundos importantes. El lanzamiento de cambios incompatibles debe seguir nuestra política de retrocompatibilidad.
Versiones de LTS
- Versión principal: Se espera que se cree una nueva versión de LTS a partir de HEAD aproximadamente cada 12 meses. Una vez que se lanza una nueva versión de LTS, esta entra de inmediato en la etapa Activa, y la versión anterior de LTS entra en la etapa de 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 parches para las versiones de LTS en las etapas activa y de mantenimiento se lancen a pedido para correcciones de errores críticos.
- Una versión LTS de Bazel entra en la etapa de Obsoleta después de estar en la etapa de Mantenimiento durante 2 años.
Para conocer las versiones planificadas, consulta nuestros problemas de versiones en GitHub.
Procedimiento y políticas de lanzamiento
En el caso de las versiones continuas, el proceso es sencillo: aproximadamente cada dos semanas, se crea una versión nueva, que se alinea con la misma base que la versión interna de Blaze de Google. Debido al programa de lanzamientos rápidos, no se realizan retroportaciones de ningún cambio a las versiones continuas.
Para las versiones LTS, se siguen el procedimiento y las políticas que se indican a continuación:
- Determina una confirmación de referencia para la versión.
- Para una nueva versión principal de LTS, la confirmación de referencia es el HEAD de la rama principal.
- Para una versión secundaria o de parche, la confirmación de referencia es el HEAD de la versión más reciente de la misma versión de LTS.
- Crea una rama de lanzamiento con el nombre de
release-<version>a partir de la confirmación de referencia. - Realiza una retroportación de los cambios a través de las PR a la rama de lanzamiento.
- La comunidad puede sugerir que se realicen retroportaciones de ciertas confirmaciones respondiendo
"
@bazel-io flag" en los problemas o las solicitudes de extracción de GitHub pertinentes para marcarlos como posibles bloqueadores de versiones. El equipo de Bazel los clasifica y decide si retroportar las confirmaciones. - Solo se pueden retroportar las confirmaciones retrocompatibles en la rama principal. Se aceptan cambios menores adicionales para resolver conflictos de combinación.
- La comunidad puede sugerir que se realicen retroportaciones de ciertas confirmaciones respondiendo
"
Realiza una retroportación de los cambios con el problema de solicitud de selección para los encargados de mantenimiento de Bazel.
Los encargados del mantenimiento de Bazel pueden solicitar que se seleccionen confirmaciones específicas en una rama de lanzamiento. Este proceso se inicia creando una solicitud de cherry-pick en GitHub. o crear a partir de ellos. Te mostramos cómo.
- Abre la solicitud de selección de cambios.
- Completa los detalles de la solicitud.
- Título: Proporciona un título conciso y descriptivo para la solicitud.
- ID de confirmación: Ingresa los ID de las confirmaciones que deseas seleccionar. 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.
- Establece el hito
- Busca la sección "Hito" y haz clic en el parámetro de configuración.
- Selecciona los bloqueadores de versiones X.Y.Z adecuados. Esta acción activa el bot de cherry-pick para que procese tu solicitud para la rama "release-X.Y.Z".
- 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 el cherry-pick. Si las confirmaciones se pueden seleccionar, lo que significa que no hay un conflicto de combinación mientras se selecciona la confirmación, el bot creará una nueva solicitud de extracción. Cuando un miembro del equipo de Bazel aprueba la solicitud de extracción, las confirmaciones se seleccionan y se combinan con la rama de la versión. Para ver un ejemplo visual de una solicitud de selección de cambios completada, consulta este ejemplo .
Identificar los bloqueadores de la versión y corregir los problemas que se encuentren en la rama de la versión
- La rama de lanzamiento se prueba con el mismo paquete de pruebas en postsubmit y downstream test pipeline en Bazel CI. El equipo de Bazel supervisa los resultados de las pruebas de la rama de lanzamiento y corrige las regresiones que se encuentren.
Crea una nueva versión candidata para lanzamiento a partir de la rama de lanzamiento cuando se resuelvan todos los bloqueadores de lanzamiento conocidos.
- La versión candidata para lanzamiento se anuncia en bazel-discuss, y el equipo de Bazel supervisa los informes de errores de la comunidad para la versión candidata.
- Si se identifican nuevos bloqueadores de la versión, vuelve al último paso y crea una nueva versión candidata para lanzamiento después de resolver todos los problemas.
- No se permite agregar funciones nuevas a la rama de la versión después de que se crea la primera versión candidata para lanzamiento. Las selecciones de cambios se limitan solo a correcciones críticas. Si se necesita una selección, el solicitante debe responder las siguientes preguntas: ¿Por qué este cambio es fundamental y qué beneficios proporciona? ¿Cuál es la probabilidad de que este cambio introduzca una regresión?
Publicar la versión candidata como la versión oficial si no se encuentran más bloqueadores de versiones
- Para las versiones de parche, publica la versión al menos dos días hábiles después de que se publique la última versión candidata.
- Para las versiones principales y secundarias, envía la versión dos días hábiles después de que se publique la última versión candidata, pero no antes de una semana después de que se publique la primera versión candidata.
- La versión solo se envía un día en el que el día siguiente es un día hábil.
- La versión se anuncia en bazel-discuss, y el equipo de Bazel supervisa y aborda los informes de errores de la comunidad para la nueva versión.
Informa regresiones
Si un usuario encuentra una regresión en una nueva versión de Bazel, una versión candidata para lanzamiento o incluso Bazel en HEAD, presenta un error en GitHub. Puedes usar Bazelisk para bisecar 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 la segunda versión candidata de 6.2.0, puedes realizar una bisección con
bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar
Puedes configurar la variable de entorno BAZELISK_SHUTDOWN o BAZELISK_CLEAN para ejecutar
los comandos de Bazel correspondientes y restablecer el estado de compilación si es necesario para
reproducir el problema. Para obtener más detalles, consulta la documentación sobre la función de bisección de Bazelisk.
Recuerda actualizar Bazelisk a la versión más reciente para usar la función de bisección.
Compatibilidad de las reglas
Si eres autor de reglas y quieres mantener la compatibilidad con diferentes versiones de Bazel, consulta la página Compatibilidad de reglas.