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 información más reciente sobre el modelo de lanzamiento de Bazel.
Matriz de compatibilidad
| Versión LTS | Etapa de compatibilidad | Última versión | Fin de la compatibilidad |
|---|---|---|---|
| Bazel 8 | Continuo | Consulta la página de lanzamientos continuos | N/A |
| Bazel 7 | Activo | 7.4.1 | Diciembre de 2026 |
| Bazel 6 | Mantenimiento | 6.5.0 | Diciembre de 2025 |
| Bazel 5 | Mantenimiento | 5.4.1 | Ene de 2025 |
| Bazel 4 | Obsoleto | 4.2.4 | enero de 2024 |
Todas las versiones LTS de Bazel se pueden encontrar en la página de versiones en 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 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íticas.
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:
- Principal: 6.0.0
- Menor: 6.1.0
- Parche: 6.1.2
- Versión preliminar: 7.0.0-pre.20230502.1
Etapas de asistencia
Para cada versión principal de Bazel, hay cuatro etapas de asistencia:
- 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. El equipo de Bazel realiza portabilidad a versiones anteriores de funciones importantes y correcciones de errores en sus versiones menores.
- Mantenimiento: Esta versión principal es una versión LTS anterior en modo de 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
- Las versiones continuas 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 LTS de Bazel.
- Las versiones continuas 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 LTS
- Versión principal: Se espera que se corte una nueva versión LTS 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 LTS de Bazel entra en la etapa de baja después de estar en la etapa de mantenimiento durante 2 años.
Para las versiones planificadas, consulta nuestros problemas de versiones en GitHub.
Políticas y procedimientos de lanzamiento
En el caso de los lanzamientos continuos, el proceso es sencillo: aproximadamente cada dos semanas, se crea una versión nueva 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 llevamos a cabo la portabilidad a versiones anteriores de los cambios a las versiones continuas.
En el caso de las versiones LTS, se siguen los procedimientos 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 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 lanzamiento con el nombre de
release-<version>a partir del commit de referencia. - Realiza la portabilidad a versiones anteriores de los cambios a través de PR a la rama de lanzamiento.
- La comunidad puede sugerir que se lleven a cabo portabilidad a versiones anteriores de ciertas confirmaciones. Para ello, debe responder “
@bazel-io flag” en los problemas o las PR relevantes de GitHub para marcarlas como posibles bloqueadores de lanzamientos. El equipo de Bazel las prioriza y decide si llevar a cabo la 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 que se lleven a cabo portabilidad a versiones anteriores de ciertas confirmaciones. Para ello, debe responder “
Se realizaron cambios de portabilidad con el problema de solicitud de selección de Bazel para los encargados de mantenimiento.
Los encargados del mantenimiento de Bazel pueden solicitar elegir confirmaciones específicas para una rama de lanzamiento. Para iniciar este proceso, crea una solicitud de selección en GitHub. o crear a partir de ellos. Te mostramos cómo.
- Abre la solicitud de selección.
- 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 seleccionar. Si hay varios confirmaciones, sepáralos con comas.
- Categoría: Especifica la categoría de la solicitud.
- Revisores: Si hay varios revisores, separa sus IDs de GitHub con comas.
- Establece el hito
- Busca la sección "Millares de visitas" y haz clic en el parámetro de configuración.
- Selecciona los bloqueadores de lanzamientos X.Y.Z adecuados. Esta acción activa el bot de selección 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 lugar, envía el problema.
El bot de selección 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 conflictos 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 seleccionan y se combinan en la rama de lanzamiento. Para ver un ejemplo visual de una solicitud de selección completada, consulta este ejemplo.
Identificar los elementos que bloquean la versión y corregir 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 encuentren.
Crea una nueva versión candidata a partir de la rama de versión cuando se resuelvan todos los bloqueadores de versión conocidos.
- 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. Las selecciones solo se limitan 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?
Publica la versión candidata como la versión oficial si no se encuentran más bloqueadores de lanzamiento.
- En el caso de las versiones de parches, envía la versión 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, 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 en bazel-discuss. El equipo de Bazel supervisa y aborda los informes de errores de la comunidad para la nueva versión.
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, 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 la función de biseccionamiento de Bazelisk.
Recuerda actualizar Bazelisk a la versión más reciente para usar la función bisect.
Compatibilidad de las reglas
Si eres autor de reglas y deseas mantener la compatibilidad con diferentes versiones de Bazel, consulta la página Compatibilidad de reglas.