Política de lanzamiento

Bazel mantiene un modelo de lanzamiento de compatibilidad a largo plazo (LTS), en el que una versión principal se actualiza cada nueve meses y el resto, mensualmente. En esta página, se aborda la política de actualización de Bazel, incluidos los candidatos de lanzamiento, los cronogramas, los anuncios y las pruebas.

Las versiones de Bazel se pueden encontrar en GitHub.

Liberar a los candidatos

Por lo general, la versión candidata para una versión nueva de Bazel se crea al comienzo de cada mes. Se realiza un seguimiento del trabajo mediante un error de lanzamiento en GitHub que indica una fecha de lanzamiento objetivo y se asigna al administrador de versiones actual. Los candidatos a versión deben pasar todas las pruebas de unidades de Bazel y no mostrar una regresión no deseada en los proyectos probados en Buildkite.

Los candidatos a los lanzamientos se anuncian en bazel-analyze. Durante los próximos días, el equipo de Bazel supervisa los informes de errores de la comunidad en busca de regresiones en los candidatos.

Cómo realizar el lanzamiento

Si no se descubren regresiones, el candidato se libera oficialmente después de una semana. Sin embargo, las regresiones pueden retrasar la publicación de una versión potencial. Si se encuentran regresiones, el equipo de Bazel aplica las selecciones de cereza correspondientes al candidato de lanzamiento para corregir esas regresiones. Si no se encuentran regresiones durante dos días consecutivos posteriores a la semana desde el primer lanzamiento de un candidato, este se libera.

Las nuevas características no se seleccionan en versión candidata a un lanzamiento después de que se cortan. Además, si un elemento nuevo tiene errores, es posible que se revierta un candidato de lanzamiento. Solo los errores que tienen el potencial de impactar o romper la compilación de lanzamiento se corrigen en una versión potencial después de que se corta.

Una versión solo se lanza un día en el que el día siguiente es un día hábil.

Si se detecta un problema crítico en la versión más reciente, el equipo de Bazel crea una versión de parche mediante la corrección de la versión. Debido a que este parche actualiza una versión existente en lugar de crear una nueva, la versión de parche potencial puede lanzarse después de dos días hábiles.

Prueba

Se ejecuta una compilación nocturna de todos los proyectos que se ejecutan en ci.bazel.build con objetos binarios de Bazel compilados en el encabezado y liberar objetos binarios. Los proyectos que se verán afectados por un cambio rotundo se notifican.

Cuando se emite una versión potencial, otros proyectos de Google como TensorFlow se prueban en su conjunto de pruebas completo con los objetos binarios de la versión. Si tienes un proyecto crítico con Bazel, te recomendamos que establezcas un proceso de prueba automatizado que haga un seguimiento del candidato actual para el lanzamiento y que informe las regresiones.