Como se anunció en la publicación de blog original, Bazel 4.0 y las versiones posteriores admiten dos pistas 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
| Versión de LTS | Etapa de compatibilidad | Última versión | Fin de la compatibilidad |
|---|---|---|---|
| Bazel 9 | Continuo | Consulta la página de lanzamientos progresivos | N/A |
| Bazel 8 | Activo | 8.3.0 | Diciembre de 2027 |
| Bazel 7 | Mantenimiento | 7.6.1 | Dic. 2026 |
| Bazel 6 | Mantenimiento | 6.5.0 | Diciembre de 2025 |
| Bazel 5 | Obsoleto | 5.4.1 | Ene. 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 de GitHub.
Control de versiones de actualización
Bazel usa un esquema de 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 LTS.
- Una versión secundaria contiene correcciones de errores y funciones retrocompatibles que se transfirieron de 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 generaría los siguientes números de versión:
- Grave: 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:
- Lanzamiento 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 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 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 brinda asistencia para esta versión principal. Todos los usuarios deben migrar a versiones LTS más recientes de Bazel.
Frecuencia de actualización
Bazel publica versiones periódicamente para dos canales de versiones.
Lanzamientos progresivos
- Los lanzamientos continuos se coordinan con el lanzamiento de Google Blaze y se realizan 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. Las marcas incompatibles se recomiendan para los cambios rotundos importantes, y 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 cree una nueva versión LTS a partir de HEAD aproximadamente cada 12 meses. Una vez que se lanza una nueva versión de LTS, esta ingresa de inmediato en la etapa Activa, y la versión de LTS anterior ingresa 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.
- Lanzamiento de parches: Se espera que se lancen nuevas versiones de parches para las versiones LTS en las etapas Activa y de Mantenimiento a pedido para correcciones de errores críticos.
- Una versión de LTS de Bazel entra en la etapa de desuso 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 los lanzamientos continuos, el proceso es sencillo: cada dos semanas, aproximadamente, se crea un nuevo lanzamiento que se alinea con la misma versión de referencia que el lanzamiento interno de Blaze de Google. Debido al cronograma de lanzamientos rápidos, no realizamos portaciones inversas de ningún cambio a los lanzamientos continuos.
En el caso de las versiones de LTS, se siguen los procedimientos y las políticas que se indican a continuación:
- Determina una confirmación de referencia para la versión.
- En el caso de una nueva versión principal de LTS, la confirmación de referencia es el HEAD de la rama principal.
- En el caso de una versión secundaria o de parche, la confirmación de referencia es el HEAD de la versión más reciente actual de la misma versión de LTS.
- Crea una rama de lanzamiento con el nombre
release-<version>a partir de la confirmación de referencia. - Realiza un backport de los cambios a través de PR en la rama de lanzamiento.
- La comunidad puede sugerir que se realice un backport de ciertas confirmaciones respondiendo "
@bazel-io flag" en los problemas o las PR pertinentes de GitHub para marcarlos como posibles bloqueadores de lanzamientos. El equipo de Bazel los clasifica y decide si se debe realizar un backport de las confirmaciones. - Solo se pueden transferir a versiones anteriores los commits compatibles con versiones anteriores en la rama principal. Se aceptan cambios menores adicionales para resolver conflictos de combinación.
- La comunidad puede sugerir que se realice un backport de ciertas confirmaciones respondiendo "
Realiza un backport de los cambios con el problema de solicitud de Cherry-Pick para los mantenedores de Bazel.
Los mantenedores de Bazel pueden solicitar que se seleccionen commits específicos para una rama de lanzamiento. Este proceso se inicia con la creación de una solicitud de cherry-pick en GitHub. o crear a partir de ellos. Te mostramos cómo.
- Abre la solicitud de cherry-pick.
- 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 transferir. Si hay varias confirmaciones, sepáralas con comas.
- Categoría: Especifica la categoría de la solicitud.
- Revisor(es): Si hay 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 la versión X.Y.Z adecuados. Esta acción activa el bot de cherry-pick para que procese tu solicitud de 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 transferir, lo que significa que no hay conflictos de combinación durante la transferencia de 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, se seleccionan los commits y se combinan con la rama de la versión. Para ver un ejemplo visual de una solicitud de cherry-pick 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 conjunto de pruebas en la canalización de pruebas posterior al envío y descendente en la CI de Bazel. El equipo de Bazel supervisa los resultados de las pruebas de la rama de lanzamiento y corrige cualquier regresión que se encuentre.
Crea un nuevo candidato para lanzamiento a partir de la rama de lanzamiento cuando se resuelvan todos los bloqueadores de lanzamiento conocidos.
- El candidato a lanzamiento se anuncia en bazel-discuss, y el equipo de Bazel supervisa los informes de errores de la comunidad para el candidato.
- Si se identifican bloqueadores de la versión nueva, vuelve al último paso y crea una nueva versión candidata después de resolver todos los problemas.
- No se permite agregar funciones nuevas a la rama de lanzamiento después de que se crea la primera versión candidata. Las transferencias de cambios se limitan solo a las correcciones críticas. Si se necesita un cherry-pick, el solicitante debe responder las siguientes preguntas: ¿Por qué este cambio es fundamental y qué beneficios proporciona? ¿Qué probabilidad hay de que este cambio introduzca una regresión?
Publicar la versión potencial como la versión oficial si no se encuentran más bloqueadores de lanzamientos
- En el caso de las versiones de parche, publícalas al menos dos días hábiles después de que se publique la última versión candidata.
- En el caso de las versiones principales y secundarias, lanza 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 en un día en el que el día siguiente es un día hábil.
- El lanzamiento se anuncia en bazel-discuss, y 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 una nueva versión de Bazel, una versión candidata o incluso Bazel en HEAD, debe informar un error en GitHub. Puedes usar Bazelisk para aislar la confirmación infractora e 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 búsqueda binaria con
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 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 bisect.
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.