Como se anunció en la entrada de blog original, Bazel y las versiones posteriores proporcionan compatibilidad con dos segmentos: versiones progresivas y compatibilidad 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 8 | Continuo | Consultar la página de lanzamiento progresivo | N/A |
| Bazel 7 | Activas | 7.2.0 | Diciembre de 2026 |
| Bazel 6 | Mantenimiento | 6.5.0 | Diciembre de 2025 |
| Bazel 5 | Mantenimiento | 5.4.1 | Enero de 2025 |
| Bazel 4 | Obsoleto | 4.2.4 | enero de 2024 |
Todas las versiones de Bazel LTS se pueden encontrar en la página de versiones en GitHub.
Control de versiones de actualización
Bazel usa un esquema major.minor.patch de control de versiones semántico.
- 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 características con portabilidad desde 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 lanzamiento nuevo de cada tipo generaría los siguientes números de versión:
- Mayor: 6.0.0
- Menor: 6.1.0
- Parche: 6.1.2
- Previo al lanzamiento: 7.0.0-pre.20230502.1
Etapas de la asistencia
Para cada versión principal de Bazel, hay cuatro etapas de compatibilidad:
- Progresiva: Esta versión principal aún está en fase previa al lanzamiento, el equipo de Bazel publica versiones progresivas desde HEAD.
- Activa: Esta versión principal es la versión activa de LTS actual. El equipo de Bazel agrega portabilidad a versiones anteriores de funciones importantes y correcciones de errores en sus versiones secundarias.
- Mantenimiento: Esta versión principal es una versión de LTS anterior en modo de mantenimiento. El equipo de Bazel solo promete aplicar correcciones de errores críticos a versiones anteriores para problemas de seguridad y compatibilidad con 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 Bazel LTS.
Frecuencia de actualización
Bazel publica con frecuencia versiones de dos segmentos.
Versiones progresivas
- Los lanzamientos progresivos 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 de Bazel con LTS.
- Las versiones progresivas pueden enviar cambios incompatibles. Se recomiendan marcas incompatibles para los cambios rotundos importantes. El lanzamiento de cambios incompatibles debe seguir nuestra política de retrocompatibilidad.
Versiones de LTS
- Lanzamiento principal: 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, entra de inmediato en la etapa Activa, y la versión de LTS anterior entra a la etapa de mantenimiento.
- Lanzamiento menor: Se espera que las nuevas versiones secundarias del segmento Active LTS se lancen una vez cada 2 meses.
- Versión de parche: Se espera que las nuevas versiones de parches para las versiones LTS en las etapas Activa y Mantenimiento se lancen a pedido para las correcciones de errores críticos.
- Una versión de Bazel LTS entra a 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 con las versiones en GitHub.
Procedimientos y políticas de lanzamiento
En el caso de los lanzamientos progresivos, el proceso es sencillo: aproximadamente cada dos semanas, se crea una versión nueva que se alinea con el mismo modelo de referencia de la versión Blaze interna de Google. Debido al programa de lanzamientos rápidos, no adaptamos ningún cambio a las versiones progresivas.
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 el lanzamiento.
- Para una nueva versión importante de LTS, la confirmación del modelo de referencia es el ENCABEZADO de la rama principal.
- En el caso de una versión secundaria o de parche, la confirmación del modelo de referencia es el ENCABEZADO 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. - 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 la portabilidad a versiones anteriores respondiendo “
@bazel-io flag” en los problemas relevantes de GitHub o en las PR para marcarlas como posibles bloqueadores de versiones. El equipo de Bazel las evalúa y decide si desea aplicar portabilidad a versiones anteriores de las confirmaciones. - Solo las confirmaciones retrocompatibles en la rama principal pueden transferirse a la versión anterior. Se aceptan cambios menores adicionales para resolver los conflictos de combinación.
- La comunidad puede sugerir ciertas confirmaciones para la portabilidad a versiones anteriores respondiendo “
Cambios de portabilidad a versiones anteriores con el problema de solicitud Cherry-pick para encargados de mantenimiento de Bazel
Los encargados de mantenimiento de Bazel pueden solicitar que se seleccionen de forma especial confirmaciones específicas para una rama de la actualización. Este proceso se inicia mediante la creación de una solicitud especial en GitHub. o crear a partir de ellos. Te mostramos cómo.
- Abre la solicitud de selección integral.
- 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.
- Category (Categoría): Especifica la categoría de la solicitud.
- Revisores: En el caso de varios revisores, separa sus ID de GitHub con comas.
- Establece el hito.
- Busca la sección "Evento importante" y haz clic en el parámetro de configuración.
- Selecciona los bloqueadores de liberación X.Y.Z adecuados. Esta acción activa el bot especial para procesar tu solicitud de la rama “release-X.Y.Z”.
- Envía el problema.
- Una vez que completes todos los detalles y se configure el hito, envía el problema.
El bot de selección detallada procesará la solicitud y notificará si las confirmaciones son aptas para esta selección. Si las confirmaciones se pueden elegir fácilmente, lo que significa que no hay conflicto 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 con cuidado y se combinan con la rama de la versión. Para ver un ejemplo visual de una solicitud de selección especial completa, consulta este ejemplo.
Identifica los bloqueadores de versiones y soluciona los problemas de la rama de la versión.
- La rama de la versión se prueba con el mismo conjunto 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 desde la rama de la versión cuando se resuelvan todos los bloqueadores de versiones conocidos.
- La versión candidata para el 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 nuevos bloqueadores de versiones, 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 la versión después de crear la primera versión candidata. Las selecciones exclusivas se limitan a las correcciones críticas. Si se necesita una selección especial, el solicitante debe responder las siguientes preguntas: ¿Por qué es fundamental este cambio y qué beneficios proporciona? ¿Cuál es la probabilidad de que este cambio introduzca una regresión?
Envía la versión candidata para el lanzamiento como la versión oficial si no se encuentran más bloqueadores.
- 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 haya publicado 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 esté disponible la última versión potencial, pero no antes de una semana después de que esté disponible la primera versión.
- La versión solo se publica en un día en que el día siguiente es hábil.
- La versión se anuncia en bazel-discuss. El equipo de Bazel supervisa y aborda los informes de errores de la comunidad de la versión nueva.
Informa regresiones
Si un usuario encuentra una regresión en una versión nueva 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 y agregar esta información en el informe de errores.
Por ejemplo, si tu compilación se ejecuta correctamente con Bazel 6.1.0, pero falla con la segunda versión potencial de 6.2.0, puedes hacer una bisición 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 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 bisect de Bazelisk.
Recuerda actualizar Bazelisk a la versión más reciente para usar la función de bisect.
Compatibilidad de reglas
Si creas reglas y quieres mantener la compatibilidad con diferentes versiones de Bazel, consulta la página Compatibilidad de reglas.