Como se anunció en la entrada de blog original, Bazel 4.0 y las versiones posteriores proporcionan compatibilidad con dos segmentos: lanzamientos progresivos y versiones de asistencia a largo plazo (LTS). En esta página, se abarca la información más reciente sobre el modelo de lanzamiento de Bazel.
Control de versiones de la versió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 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 con portabilidad a versiones anteriores de la rama principal.
- Una actualización de parche contiene correcciones de errores críticos.
Además, las versiones previas al lanzamiento se indican cuando se agrega un guion y un sufijo de fecha al siguiente número de versión principal.
Por ejemplo, una versión nueva de cada tipo generaría los siguientes números de versión:
- Importante: 6.0.0
- Menor: 6.1.0
- Parche: 6.1.2
- Previo al lanzamiento: 7.0.0-pre.20230502.1
Etapas de asistencia
Para cada versión principal de Bazel, hay cuatro etapas de compatibilidad:
- En curso: Esta versión principal aún está en fase previa al lanzamiento. El equipo de Bazel publica versiones progresivas desde el encabezado.
- Active: Esta versión principal es la versión de LTS activa actual. El equipo de Bazel incorpora 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 brindar portabilidad a versiones anteriores de las correcciones de errores críticos para problemas de seguridad y compatibilidad con el SO en esta versión de LTS.
- Obsoleto: El equipo de Bazel ya no proporciona compatibilidad con esta versión principal, por lo que todos los usuarios deben migrar a versiones más recientes de LTS de Bazel.
Frecuencia de actualización
Bazel publica regularmente versiones para dos segmentos.
Lanzamientos progresivos
- Los lanzamientos progresivos se coordinan con el lanzamiento de Google Blaze y se lanzan desde el encabezado alrededor de cada dos semanas. Es una vista previa de la próxima versión de Bazel LTS.
- Los lanzamientos progresivos pueden enviar cambios incompatibles. Se recomiendan marcas incompatibles para cambios rotundos importantes. El lanzamiento de cambios incompatibles debe seguir nuestra política de retrocompatibilidad.
Versiones de LTS
- Lanzamiento importante: Se espera que una versión de LTS nueva se corte de HEAD aproximadamente cada 12 meses. Una vez que se publica una nueva versión de LTS, entra de inmediato a la etapa Activa, y la versión de LTS anterior pasa a la etapa de Mantenimiento.
- Lanzamiento secundario: Se espera que las versiones secundarias nuevas en el segmento activo LTS se lancen una vez cada 2 meses.
- Lanzamiento de parches: Se espera que las versiones de parche nuevas para las versiones LTS en las etapas Activa y Mantenimiento se lancen a pedido para correcciones de errores críticos.
- Una versión de LTS de Bazel entra en la etapa Obsoleto después de estar en la etapa de Mantenimiento durante 2 años.
Para conocer los lanzamientos planificados, consulta nuestros problemas relacionados en GitHub.
Matriz de compatibilidad
| Versión de LTS | Etapa de compatibilidad | Última versión | Fin de la compatibilidad |
|---|---|---|---|
| Bazel 7 | Continuo | Consultar la página de versiones de GitHub | No disponible |
| Bazel 6 | Activo | 6.4.0 | Diciembre de 2025 |
| Bazel 5 | Mantenimiento | 5.4.1 | Enero de 2025 |
| Bazel 4 | Mantenimiento | 4.2.4 | enero de 2024 |
Puedes encontrar todas las versiones de Bazel en la página de versiones de GitHub.
Procedimiento y políticas del lanzamiento
En el caso de los lanzamientos progresivos, el proceso es sencillo: se crea una nueva versión aproximadamente cada dos semanas que se alinea con el mismo modelo de referencia que la versión interna de Blaze de Google. Debido al programa de lanzamientos rápidos, no admitimos ningún cambio en los lanzamientos progresivos.
Para las versiones de LTS, se siguen el procedimiento y las políticas que se indican a continuación:
- Determina una confirmación del modelo de referencia para la versión.
- Para una nueva versión importante de LTS, la confirmación del modelo de referencia es el ENCABEZADO de la rama principal.
- Para una versión secundaria o de parche, la confirmación del modelo de referencia es el HEAD de la versión más reciente de la misma versión de LTS.
- Crea una rama de la versión en el nombre de
release-<version>a partir de la confirmación del modelo de referencia. - Adapta los cambios a través de los PR a la rama de la versión.
- La comunidad puede sugerir ciertas confirmaciones para usar en la portabilidad a versiones anteriores respondiendo
“
@bazel-io flag” en problemas relevantes de GitHub o en los PR para marcarlas como posibles bloqueadores de versiones, el equipo de Bazel las clasifica y decide si es necesario portabilidad a versiones anteriores de las confirmaciones. - Solo las confirmaciones retrocompatibles en la rama principal se pueden adaptar. Se aceptan cambios menores adicionales para resolver conflictos de combinación.
- La comunidad puede sugerir ciertas confirmaciones para usar en la portabilidad a versiones anteriores respondiendo
“
- Identifica bloqueadores de versiones y soluciona problemas que se encuentren en la rama de la versión.
- La rama de actualización se prueba con el mismo paquete de pruebas en postsubmit y en la canalización de prueba descendente en Bazel CI. El equipo de Bazel supervisa los resultados de las pruebas de la rama de la versión y corrige las regresiones encontradas.
- Crea una nueva versión candidata para la rama de lanzamiento cuando se resuelvan todos los bloqueadores conocidos.
- La versión candidata para lanzamiento se anuncia en bazel-discuss; el equipo de Bazel supervisa los informes de errores de la comunidad del candidato.
- Si se identifican nuevos bloqueadores de versiones, vuelve al último paso y crea una nueva versión potencial después de resolver todos los problemas.
- No se podrán agregar funciones nuevas a la rama de la versión después de la creación de la primera versión candidata.
- Envía la versión candidata para el lanzamiento como la versión oficial si no se encuentran más bloqueadores de lanzamiento.
- En el caso de las versiones de parche, envía la versión al menos dos días hábiles después de que se lance la última versión candidata.
- En el caso de las versiones principales y secundarias, envíalas dos días hábiles después de que se haya publicado la última versión candidata, pero no antes de una semana después de que se haya lanzado la primera versión candidata para 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 y, luego, el equipo de Bazel supervisa y aborda los informes de errores de la comunidad para la versión nueva.
Informa regresiones
Si un usuario encuentra una regresión en una nueva versión de Bazel, una versión candidata o incluso Bazel en el ENCABEZADO, informa el error en GitHub. Puedes usar Bazelisk para dividir la confirmación culpable 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 dividirla mediante
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 a fin de 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 bisect de Bazelisk.
Recuerda actualizar Bazelisk a la versión más reciente para usar la función de bisecación.
Compatibilidad de las reglas
Si eres el autor de reglas y quieres mantener la compatibilidad con diferentes versiones de Bazel, consulta la página Compatibilidad de reglas.