Para obtener documentación sobre versiones estables, usa el menú desplegable "Documentos con versiones". La vista predeterminada refleja la versión más reciente en el encabezado.

Se usó la API de Cloud Translation para traducir esta página.

Modelo de lanzamiento

Informar un problema Ver fuente

Como se anunció en la entrada de blog original, las versiones 4.0 y posteriores de Bazel ofrecen compatibilidad con dos segmentos: versiones progresivas y versiones con compatibilidad a largo plazo (LTS). En esta página, se aborda 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	Consulta la página del lanzamiento progresivo	N/A
Bazel 7	Activo	7.1.1	Dic de 2026
Bazel 6	Mantenimiento	6.5.0	Diciembre de 2025
Bazel 5	Mantenimiento	5.4.1	Enero de 2025
Bazel 4	Funciones obsoletas	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 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 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 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:

Principal: 6.0.0
Menor: 6.1.0
Parche: 6.1.2
Antes del lanzamiento: 7.0.0-pre.20230502.1

Etapas de la asistencia

Para cada versión principal de Bazel, hay cuatro etapas de compatibilidad:

En etapas: Esta versión principal aún se encuentra en fase previa al lanzamiento, por lo que el equipo de Bazel publica versiones progresivas desde el encabezado.
Activa: Esta versión principal es la versión de LTS activa actual. El equipo de Bazel incorpora una portabilidad a versiones anteriores de funciones y correcciones de errores importantes en 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 los problemas de seguridad y de compatibilidad con el SO en esta versión de LTS.
Obsoleto: El equipo de Bazel ya no proporciona compatibilidad con esta versión principal; todos los usuarios deben migrar a versiones más recientes de LTS de Bazel.

Frecuencia de actualización

Bazel publica con frecuencia lanzamientos para dos segmentos.

Lanzamientos progresivos

Las versiones progresivas se coordinan con la versión de Google Blaze y se lanzan desde el encabezado HEAD alrededor de cada dos semanas. Es una vista previa de la próxima versión de LTS de Bazel.
Las versiones progresivas pueden enviar cambios incompatibles. Se recomiendan marcas incompatibles para los cambios rotundos más importantes. El lanzamiento de cambios incompatibles debe seguir nuestra política de retrocompatibilidad.

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 publica una nueva versión de LTS, entra inmediatamente en la etapa Activa, y la versión anterior de LTS pasa a la etapa de mantenimiento.
Versión secundaria: Se espera que las nuevas versiones secundarias del segmento Active LTS se lancen una vez cada 2 meses.
Lanzamiento de parches: Se espera que las nuevas versiones de parche para las versiones de LTS en las etapas Activa y Mantenimiento se lancen on demand para correcciones de errores críticos.
Una versión de LTS de Bazel entra en la etapa obsoleta después de pasar a la etapa de mantenimiento durante 2 años.

Para ver los lanzamientos planificados, consulta nuestros problemas de lanzamiento en GitHub.

Políticas y procedimiento de lanzamiento

Para los lanzamientos progresivos, el proceso es sencillo: aproximadamente cada dos semanas, se crea una nueva versión 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 a las versiones progresivas.

Para las versiones de LTS, se siguen el procedimiento y las políticas que se indican a continuación:

Determina una confirmación de modelo de referencia para la versión.
- Para una nueva versión importante 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 del modelo de referencia es el HEAD de la versión más reciente actual 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 los PR para la rama de la versión
- La comunidad puede sugerir la portabilidad a versiones anteriores de ciertas confirmaciones respondiendo “@bazel-io flag” en problemas relevantes de GitHub o PR para marcarlas como posibles bloqueadores de versiones. El equipo de Bazel las clasifica y decide si es necesario portabilidad para versiones anteriores de las confirmaciones.
- Solo se pueden adaptar las confirmaciones retrocompatibles en la rama principal. Se aceptan cambios menores adicionales para resolver conflictos de combinación.
Portabilidad a versiones anteriores de los cambios con el problema de solicitud Cherry-Pick para encargados de mantenimiento de Bazel
- Los encargados de mantenimiento de Bazel pueden solicitar que se elijan confirmaciones específicas para una rama de la versión. Este proceso se inicia mediante la creación de una solicitud de selección puntual en GitHub. o crear a partir de ellos. Te mostramos cómo.
  1. Abre la solicitud de selección de cerezas.
  2. 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 varias confirmaciones, sepáralas con comas.
    - Categoría: especifica la categoría de la solicitud.
    - Revisores: En el caso de varios revisores, separa sus ID de GitHub con comas.
  3. Establece el evento importante.
    - Busca la sección "Hito" 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 adecuado para procesar tu solicitud de la rama “release-X.Y.Z”.
  4. Envía el problema
    - Una vez que completes todos los detalles y se establezca el hito, envía el problema.
- El bot procesará la solicitud y notificará si las confirmaciones son aptas para esta opción. Si las confirmaciones se pueden seleccionar manualmente, 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 eligen y combinan con la rama de lanzamiento. Para ver un ejemplo visual de una solicitud de selección de cerezas completada, consulta este ejemplo.
Identifica bloqueadores de versiones y soluciona problemas encontrados en la rama de la versión.
- La rama de la versión se prueba con el mismo paquete de pruebas en postsubmit y canalización de prueba descendente en Bazel CI. El equipo de Bazel supervisa los resultados de las pruebas de la rama de la actualización y corrige las regresiones encontradas.
Crea una versión candidata nueva desde la rama de lanzamiento cuando se resuelvan todos los bloqueadores de versiones conocidos.
- La versión candidata para el 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 un nuevo candidato para el lanzamiento después de resolver todos los problemas.
- No se pueden agregar funciones nuevas a la rama de la versión después de crear la primera versión candidata.
Envía al candidato de lanzamiento como versión oficial si no se encuentran más bloqueadores para la liberación.
- En el caso de las versiones de parche, envía la versión al menos dos días hábiles después de que esté disponible 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 candidata, pero no antes de una semana después de que se lance la primera.
- La versión solo se publica un día en que el día siguiente es un día hábil.
- La versión se anuncia en bazel-discuss; el equipo de Bazel supervisa y aborda los informes de errores de la comunidad para la nueva versión.

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 un error en GitHub. Puedes usar Bazelisk para dividir la confirmación responsable e incluir esta información en el informe de errores.

Por ejemplo, si tu compilación tiene éxito con Bazel 6.1.0, pero falla con la segunda versión candidata de lanzamiento de 6.2.0, puedes dividirla a través de

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

Puedes configurar las variables 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 Bisect.

Compatibilidad de las reglas

Si eres autor de reglas y quieres mantener la compatibilidad con diferentes versiones de Bazel, consulta la página Compatibilidad de reglas.