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.

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.

Matriz de compatibilidad

Versión de 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.

Nota: Las versiones de Bazel anteriores a Bazel 4 ya no son compatibles; los usuarios de Bazel sí se recomienda actualizar a la versión más reciente de LTS o usar versiones progresivas si quieren estar al tanto de los cambios más recientes en HEAD.

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. 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.
5. 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.
6. 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.