Política de lanzamiento

Informar un problema Ver fuente Noche {/2/}}

Bazel mantiene un modelo de lanzamiento de asistencia a largo plazo (LTS), en el que se lanza una versión principal cada nueve meses y las versiones secundarias se lanzan mensualmente. En esta página, se aborda la política de lanzamiento de Bazel, incluidas las versiones candidatas, los cronogramas, los anuncios y las pruebas.

Puedes encontrar las versiones de Bazel en GitHub.

Versiones potenciales

Por lo general, las versiones candidatas para una versión nueva de Bazel se crean al principio de cada mes. El trabajo se rastrea con un error de actualización en GitHub que indica una fecha de lanzamiento objetivo y se asigna al Administrador de versiones actual. Las versiones candidatas deben pasar todas las pruebas de unidades de Bazel y no deben mostrar regresión no deseada en los proyectos que se probaron en Buildkite.

Las versiones candidatas se anuncian en bazel-discuss. 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.

En proceso de lanzamiento

Si no se descubren regresiones, el candidato se libera 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 los selectores correspondientes al lanzamiento candidato para corregir esas regresiones. Si no se encuentran más regresiones durante dos días hábiles consecutivos a partir de una semana desde el primer lanzamiento candidato, se libera.

Las funciones nuevas no se seleccionan cuidadosamente en una versión candidata después de que se cortan. Además, si una función nueva presenta errores, es posible que se revierta desde una versión candidata. Solo los errores que tienen el potencial de afectar un alto nivel o romper la compilación de lanzamiento se corrigen en una versión candidata después de que se corta.

Las versiones solo se publican en días hábiles que al día siguiente son hábiles.

Si se encuentra un problema crítico en la versión más reciente, el equipo de Bazel crea una versión de parche mediante la aplicación de la corrección a la versión. Debido a que este parche actualiza una versión existente en lugar de crear una nueva, la versión candidata de 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 objetos binarios de Bazel compilados en el encabezado y con objetos binarios de actualización. Los proyectos que se verán afectados por un cambio rotundo reciben una notificación.

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