Como se anunció en la entrada de blog original, Bazel 4.0 y versiones posteriores admiten dos segmentos de lanzamiento: lanzamientos continuos y de asistencia a largo plazo (LTS). En esta página, se incluye la última información sobre el modelo de lanzamiento de Bazel.
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 retrocompatibles y funciones que se portaron desde la rama principal.
- Una versión de parche contiene correcciones de errores críticos.
Además, las versiones previas al lanzamiento se indican con un guion y un sufijo de fecha al siguiente número de versión principal.
Por ejemplo, una nueva versión de cada tipo generaría estos números de versión:
- Mayor: 6.0.0
- Menor: 6.1.0
- Parche: 6.1.2
- Versión preliminar: 7.0.0-pre.20230502.1
Etapas de la asistencia
Para cada versión principal de Bazel, hay cuatro etapas de compatibilidad:
- Continua: Esta versión principal aún está en versión preliminar. El equipo de Bazel publica versiones continuas desde HEAD.
- Activo: Esta versión principal es la versión LTS activa actual. Bazel agrega funciones importantes y correcciones de errores a sus lanzamientos menores.
- Mantenimiento: Esta versión principal es una versión de LTS anterior en mantenimiento. . El equipo de Bazel solo promete realizar la portabilidad a versiones anteriores de las correcciones de errores críticas para problemas de seguridad y compatibilidad con el SO en esta versión LTS.
- Obsoleto: El equipo de Bazel ya no brinda asistencia para esta versión principal. Todos los usuarios deben migrar a versiones LTS de Bazel más recientes.
Frecuencia de actualización
Bazel publica versiones con regularidad para dos segmentos.
Lanzamientos continuos
- Los lanzamientos progresivos se coordinan con el lanzamiento de Google Blaze y se lanzan de HEAD aproximadamente cada dos semanas. Es una vista previa de la próxima versión LTS de Bazel.
- Las versiones progresivas 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
- Lanzamiento importante: Se espera que una nueva versión de LTS se corte de HEAD aproximadamente cada 12 meses. Una vez que se lanza una nueva versión de LTS, esta entra de inmediato a la etapa Activa, y la versión de LTS anterior entra a la etapa de Mantenimiento.
- Versión menor: Se espera que las nuevas versiones menores del segmento de LTS activo se lancen una vez cada 2 meses.
- Lanzamiento de parches: Se espera que las nuevas versiones de parches para las versiones LTS en las etapas Activa y de mantenimiento se lancen a pedido para corregir errores críticos.
- Una versión de Bazel LTS entra a la etapa Baja después de estar en Etapa de mantenimiento durante 2 años.
Para conocer los lanzamientos planificados, consulta nuestro lanzamiento problemas en GitHub.
Matriz de compatibilidad
| Versión LTS | Etapa de compatibilidad | Última versión | Fin de la compatibilidad |
|---|---|---|---|
| Bazel 7 | Continuo | Consulta la página de versiones de GitHub | N/A |
| 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 esta versión. en GitHub.
Procedimiento de lanzamiento y políticas
Para los lanzamientos progresivos, el proceso es sencillo: aproximadamente cada dos semanas, se crea un una nueva versión en línea con la misma base de referencia que la versión Lanzamiento de Blaze. Debido al programa de lanzamientos rápidos, no llevamos a cabo la portabilidad a versiones anteriores de los cambios 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 del modelo de referencia es el HEAD de la rama principal.
- Para una versión menor o de parche, la confirmación del modelo de referencia es el HEAD de la versión más reciente actual de la misma versión LTS.
- Crea una rama de la versión en el nombre de
release-<version>a partir del modelo de referencia confirmar. - Portabilidad a versiones anteriores de los cambios a través de PR a la rama de la versión
- La comunidad puede sugerir ciertas confirmaciones para que se porten a versiones anteriores respondiendo
“
@bazel-io flag” sobre asuntos relevantes de GitHub o PR para marcarlos como posibles bloqueadores de lanzamientos, el equipo de Bazel los evalúa y decide si y portabilidad a versiones anteriores de las confirmaciones. - Solo se pueden portar las confirmaciones retrocompatibles en la rama principal. Se aceptan cambios menores adicionales para resolver conflictos de combinación.
- La comunidad puede sugerir ciertas confirmaciones para que se porten a versiones anteriores respondiendo
“
- Identifica los bloqueadores de versiones y soluciona los problemas de la rama de la versión.
- 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 encuentren.
- Crea una nueva versión candidata desde la rama de la versión cuando todos los
se resuelven los bloqueadores de versiones.
- La versión candidata se anuncia en bazel-discuss. El equipo de Bazel supervisa los informes de errores de la comunidad para la versión candidata.
- Si se identifican nuevos bloqueadores de lanzamiento, vuelve al último paso y crea una nueva versión candidata después de resolver todos los problemas.
- No se pueden agregar funciones nuevas a la rama de lanzamiento después de que se crea la primera versión candidata.
- Envía la versión candidata para el lanzamiento como versión oficial si no hay más versiones.
se encuentran bloqueadores
- En el caso de las versiones de parches, envía la actualización al menos dos días hábiles después. aparece la última versión candidata.
- En el caso de 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 en un día en el que el siguiente es un día hábil.
- El lanzamiento se anuncia el bazel-debate. el equipo de Bazel supervisa y aborda los informes de errores de la comunidad para el nuevo lanzamiento.
Informa regresiones
Si un usuario encuentra una regresión en una nueva versión de Bazel, una versión candidata o incluso Bazel en HEAD, informa un error en GitHub. Puedes usar Bazelisk para dividir la confirmación del error 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 hacer una bisecció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 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 Bazelisk
atributo de bisect.
Recuerda actualizar Bazelisk a la versión más reciente para usar bisect. .
Compatibilidad de reglas
Si eres el autor de una regla y deseas mantener la compatibilidad con diferentes versiones de Bazel, consulta la regla Compatibilidad.