Como se anunció en la entrada de blog original, Bazel 4.0 y las versiones posteriores admiten dos segmentos: los lanzamientos progresivos y los lanzamientos de asistencia a largo plazo (LTS). En esta página, se aborda la información más reciente sobre el modelo de lanzamiento de Bazel.
Control de versiones
Bazel usa un esquema de control de versiones semántico major.minor.patch.
- Una versión principal contiene funciones que no son compatibles 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 trasladan 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, una versión nueva de cada tipo generaría los siguientes números de versión:
- Importante: 6.0.0
- Menor: 6.1.0
- Parche: 6.1.2
- Versión previa al lanzamiento: 7.0.0-pre.20230502.1
Etapas de asistencia
Para cada versión principal de Bazel, hay cuatro etapas de compatibilidad:
- Lanzamiento: Esta versión principal aún está en lanzamiento previo, y el equipo de Bazel publica versiones progresivas de HEAD.
- Activa: Esta versión principal es la versión activa actual de LTS. El equipo de Bazel porta información importante y correcciones de errores a sus versiones secundarias.
- Mantenimiento: Esta versión principal es una versión LTS antigua en modo de mantenimiento. El equipo de Bazel solo promete realizar portabilidad a versiones anteriores para corregir errores críticos relacionados con problemas de seguridad y compatibilidad con SO en esta versión LTS.
- Obsoleto: el equipo de Bazel ya no admite esta versión principal, todos los usuarios deberían migrar a las versiones más recientes de Bazel LTS.
Frecuencia de actualización
Bazel publica versiones de dos segmentos con regularidad.
Lanzamientos progresivos
- Los lanzamientos progresivos se coordinan con los lanzamientos de Google Blaze y se lanzan a partir de HEAD aproximadamente 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 recomienda usar marcas no compatibles para realizar cambios rotundos importantes. La implementación de cambios incompatibles debe cumplir con nuestra política de retrocompatibilidad.
Versiones LTS
- Versión principal: Se espera que una nueva versión LTS se corte de HEAD aproximadamente cada 12 meses. Una vez que se lanza una nueva versión de LTS, pasa inmediatamente a la etapa activa y la versión anterior ingresa a la etapa de mantenimiento.
- Versión secundaria: Se espera que los nuevos lanzamientos menores en el segmento de LTS activo se liberen una vez cada 2 meses.
- Versión de parche: Se espera que las versiones de parche nuevas para las versiones de LTS en las etapas activa y de mantenimiento se publiquen según demanda para la corrección de errores críticos.
- Una versión de LTS de Bazel ingresa a la etapa obsoleta después de permanecer en la etapa de mantenimiento durante 2 años.
Para los lanzamientos planificados, consulta nuestros problemas de lanzamiento en GitHub.
Matriz de compatibilidad
| Versión 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 | Activos | 6.3.2 | Diciembre de 2025 |
| Bazel 5 | Mantenimiento | 5.4.1 | Ene‐2025 |
| Bazel 4 | Mantenimiento | 4.2.4 | enero de 2024 |
Todas las versiones de Bazel se pueden encontrar en la página de versiones en GitHub.
Políticas y procedimiento de lanzamiento
Para los lanzamientos progresivos, el proceso es sencillo: alrededor de cada dos semanas, se crea un lanzamiento nuevo que se alinea con el mismo modelo de referencia que el lanzamiento interno de Blaze de Google. Debido al programa de lanzamientos rápidos, no llevamos ningún cambio en los lanzamientos progresivos.
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 la versión.
- Para una nueva actualización importante de LTS, la confirmación del modelo de referencia es el HEAD de la rama principal.
- Para una versión secundaria o de parche, la confirmación de referencia es el HEAD de la versión más reciente de la misma versión LTS.
- Crea una rama de la versión a nombre de
release-<version>desde la confirmación del modelo de referencia. - La portabilidad a versiones anteriores ahora se realiza mediante RR.PP. en la rama de la versión.
- La comunidad puede sugerir la portabilidad de ciertas confirmaciones mediante “
@bazel-io flag" sobre problemas relevantes de GitHub o relaciones públicas para marcarlas como posibles bloqueadores de lanzamientos, el equipo de Bazel las clasifica y decide si deben portar las confirmaciones. - Solo se pueden realizar portabilidad a versiones anteriores de las confirmaciones retrocompatibles en la rama principal; se aceptan cambios menores adicionales para resolver conflictos de combinación.
- La comunidad puede sugerir la portabilidad de ciertas confirmaciones mediante “
- Identifica los bloqueadores de versiones y soluciona los problemas que se encuentran 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 la prueba de la rama de lanzamiento y corrige las regresiones que se hayan encontrado.
- Crea una nueva versión potencial de 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-debate, el equipo de Bazel supervisa los informes de errores de la comunidad.
- Si se identifican nuevos bloqueadores de versiones, vuelve al último paso y crea una nueva versión potencial después de resolver todos los problemas.
- Las funciones nuevas no se pueden agregar a la rama de la versión después de crear la primera versión.
- Envía al candidato como la versión oficial si no se encuentran otros bloqueadores de versiones.
- Para 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.
- En el caso de las versiones principales y secundarias, envía el lanzamiento dos días hábiles después de que se publique la última versión, pero no antes de que transcurra una semana desde que se publique la primera versión.
- La versión solo se envía un día en el que el día siguiente es un día hábil.
- La versión se anuncia en bazel-talk, el equipo de Bazel supervisa y soluciona los informes de errores de la comunidad para la versión nueva.
Informar regresiones
Si un usuario encuentra una regresión en un lanzamiento nuevo de Bazel, un candidato de lanzamiento o incluso Bazel en HEAD, informa un error en GitHub. Puedes usar Bazelisk para dividir la confirmación de culpables y, además, 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 6.2.0, puedes dividir los datos mediante
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
a fin de reproducir el problema. Para obtener más detalles, consulta la documentación sobre la función de bisecto de Bazelisk.
Recuerda actualizar Bazelisk a la versión más reciente para usar la función de bisecto.
Compatibilidad de la regla
Si eres autor de reglas y deseas mantener la compatibilidad con diferentes versiones de Bazel, consulta la página Compatibilidad de reglas.