Bazel mantiene un modelo de lanzamiento de compatibilidad a largo plazo (LTS), en el que se lanza una versión principal cada nueve meses y versiones secundarias cada mes. En esta página, se trata la política de versiones de Bazel, incluidos los candidatos a lanzamiento, los cronogramas, los anuncios y las pruebas.
Puedes encontrar las versiones de Bazel en GitHub.
Versiones candidatas para lanzamiento
Por lo general, se crea una versión candidata para una nueva versión de Bazel al comienzo de cada mes. El trabajo se realiza un seguimiento a través de un error de lanzamiento en GitHub que indica una fecha de lanzamiento objetivo y se asigna al administrador de lanzamientos actual. Las versiones candidatas deben aprobar todas las pruebas de unidades de Bazel y no mostrar ninguna regresión no deseada en los proyectos probados en Buildkite.
Las versiones candidatas se anuncian en bazel-discuss. En los próximos días, el equipo de Bazel supervisará los informes de errores de la comunidad para detectar cualquier regresión en las versiones candidatas.
Liberación
Si no se descubren regresiones, la versión candidata se lanza oficialmente después de una semana. Sin embargo, las regresiones pueden retrasar el lanzamiento de una versión candidata. Si se encuentran regresiones, el equipo de Bazel aplica las selecciones correspondientes al candidato a lanzamiento para corregirlas. Si no se encuentran más regresiones durante dos días hábiles consecutivos a partir de una semana después del primer candidato a lanzamiento, se lanza el candidato.
No se agregan funciones nuevas a una versión candidata después de que se lanza. Además, si una función nueva tiene errores, es posible que se revierta desde una versión candidata. En una versión candidata, solo se corrigen los errores que tienen el potencial de afectar o interrumpir gravemente la compilación de la versión.
Los lanzamientos solo se realizan en días en los que el día siguiente es 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 aplicando la corrección a la versión. Dado que este parche actualiza una versión existente en lugar de crear una nueva, la versión candidata del parche se puede lanzar 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 los objetos binarios de Bazel compilados en la versión principal y los objetos binarios de la versión. Se notifica a los proyectos que se verán afectados por un cambio disruptivo.
Cuando se lanza una versión candidata, otros proyectos de Google, como TensorFlow, se prueban en su conjunto completo de pruebas con los archivos binarios de la versión candidata. Si tienes un proyecto crítico que usa Bazel, te recomendamos que establezcas un proceso de pruebas automatizadas que haga un seguimiento de la versión candidata actual y que informe cualquier regresión.