Modelo de lanzamiento

Informar un problema . Ver fuente Por la noche · 7.2 · 7.1 · 7.0 · 6.5 · 6.4

Como se anunció en el blog original publicación, Bazel Las versiones 4.0 y posteriores admiten dos segmentos: lanzamiento de versiones y de asistencia a largo plazo (LTS). En esta página, se incluye la última información 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 Activo 7.2.1 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 versión en GitHub.

Control de versiones de actualización

Bazel usa un major.minor.patch semántico. Control de versiones.

  • Un lanzamiento 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 funciones y correcciones de errores retrocompatibles. con portabilidad a versiones anteriores de 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 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, por lo que el equipo de Bazel publica lanzamientos progresivos desde HEAD.
  • Activa: Esta versión principal es la versión activa de LTS 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 aplicar correcciones de errores críticos a versiones anteriores para los siguientes dispositivos: problemas de seguridad y compatibilidad de SO en esta versión de LTS.
  • Obsoleto: El equipo de Bazel ya no proporciona asistencia para este principal. 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 de HEAD aproximadamente cada dos semanas. Es una vista previa de las próximas LTS de Bazel lanzamiento.
  • Las versiones progresivas pueden enviar cambios incompatibles. Las marcas incompatibles son se recomienda para cambios rotundos importantes, que se lanzan cambios incompatibles debe seguir nuestra retrocompatibilidad política.

Versiones de LTS

  • Lanzamiento importante: Se espera que una nueva versión de LTS se corte de HEAD aproximadamente cada 12 meses. Cuando se lanza una nueva versión de LTS, entra inmediatamente en el estado y la anterior pasa a la de mantenimiento.
  • Lanzamiento menor: Se espera que las nuevas versiones secundarias del segmento Active LTS se lanzan una vez cada 2 meses.
  • Versión de parche: Nuevas versiones de parches para las versiones LTS en entornos activos y Se espera que las etapas de mantenimiento se publiquen a pedido en caso de errores críticos soluciones.
  • 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 nuestro lanzamiento problemas 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 implementamos cambios en la versión anterior a lanzamientos progresivos.

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

  1. 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 .
    • Para una versión secundaria o de parche, la confirmación del modelo de referencia es el ENCABEZADO del con la versión más reciente actual de la misma versión de LTS.
  2. Crea una rama de la versión en el nombre de release-<version> a partir del modelo de referencia confirmar.
  3. 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 portabilidad a versiones anteriores de las confirmaciones.
    • Solo las confirmaciones retrocompatibles en la rama principal pueden tener portabilidad a versiones anteriores Se aceptan cambios menores adicionales para resolver conflictos de combinación.

  4. 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 confirmaciones específicas. en una rama de la versión. Este proceso se inicia creando un cherry-pick en GitHub. o crear a partir de ellos. Te mostramos cómo.

      1. Abre la solicitud de selección integral.
      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 desees. y los mejores. Si hay varias confirmaciones, separa con comas.
        • Category (Categoría): Especifica la categoría de la solicitud.
        • Revisores: Si hay varios revisores, separa sus GitHub los IDs con comas.
      3. Establece el hito
        • Encuentra el "logro" 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 cherry-pick para procesar tu solicitud. para la versión “release-X.Y.Z” .
      4. Envía el problema
        • Una vez que hayas rellenado todos los detalles y establecido el hito, envía el problema.

    • El bot cherry-pick procesará la solicitud y notificará si las confirmaciones son aptas para una selección exclusiva. Si las confirmaciones se pueden elegir fácilmente, lo que significa que no hay conflicto de combinación mientras se elige la confirmación, luego el bot creará una solicitud de extracción nueva. Cuando el comando Pull aprobada por un miembro del equipo de Bazel, el las confirmaciones se eligen cuidadosamente y se combinan con la rama de la versión. Para ver un ejemplo visual de una solicitud de selección especial, consultar este ejemplo de Google Cloud.

  5. 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 canalización de prueba descendente en Bazel CI. El equipo de Bazel supervisa los resultados de las pruebas de la versión. y corrige cualquier regresión encontrada.

  6. Crea una nueva versión candidata desde la rama de la versión cuando todos los se resuelven los bloqueadores de versiones.

    • El candidato para el lanzamiento se anuncia el bazel-debate. el equipo de Bazel supervisa los informes de errores de la comunidad para el candidato.
    • Si se identifican bloqueadores de nuevas versiones, regresa al último paso y crea una nueva versión candidata después de resolver todos los problemas.
    • No se podrán agregar nuevas funciones a la rama de la versión después de la se crea la primera versión candidata. se limitan a los aspectos esenciales y para corregir errores. Si se necesita una selección especial, el solicitante debe responder la preguntas: ¿Por qué es fundamental este cambio y cuáles son los beneficios proporciona? ¿Cuál es la probabilidad de que este cambio introduzca una con una regresión lineal?

  7. 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 actualizaciones de parches, envía la actualización al menos dos días hábiles después. aparece la última versión candidata.
    • Para los lanzamientos principales y menores, se envía a los dos días hábiles posteriores al lanzamiento. ya se lanzó la candidata para el último lanzamiento, pero no antes de una semana sale la primera versión candidata.
    • El lanzamiento solo se publica en un día en que el día siguiente corresponde a una empresa día.
    • 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, la versión candidata o incluso Bazel en el TÍTULO, informa un error en GitHub: Puedes usar Bazelisk dividirá el compromiso culpable e incluirá esta información en el error. .

Por ejemplo, si tu compilación tiene éxito con Bazel 6.1.0, pero falla con la segunda versión candidata de 6.2.0, puedes dividir 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 que se ejecute comandos de Bazel correspondientes para restablecer el estado de compilación si es necesario reproducir el problema. Para obtener más detalles, consulta la documentación sobre Bazelisk atributo bisect.

Recuerda actualizar Bazelisk a la versión más reciente para usar bisect. .

Compatibilidad de reglas

Si usted es el autor de una regla y desea mantener la compatibilidad con diferentes versiones de Bazel, consulta la regla Compatibilidad.