Compatibilidad de las reglas

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

Las reglas de Bazel Starlark pueden interrumpir la compatibilidad con las versiones de Bazel LTS en los siguientes dos casos:

  1. La regla interrumpe la compatibilidad con las versiones futuras de LTS porque se quita una función de la que depende de Bazel en HEAD.
  2. La regla interrumpe la compatibilidad con las versiones de LTS actuales o anteriores porque una función de la que depende solo está disponible en las versiones más recientes de Bazel LTS.

Mientras tanto, la regla en sí también puede enviar cambios incompatibles para sus usuarios. Cuando se combina con cambios rotundos en Bazel, actualizar la versión de la regla y la versión de Bazel a menudo puede ser una fuente de frustración para los usuarios de Bazel. En esta página, se explica cómo los autores de reglas deben mantener la compatibilidad de las reglas con Bazel para que los usuarios puedan actualizar Bazel y las reglas con mayor facilidad.

Proceso de migración administrable

Si bien obviamente no es posible garantizar la compatibilidad entre cada versión de Bazel y cada versión de la regla, nuestro objetivo es garantizar que el proceso de migración siga siendo administrable para los usuarios de Bazel. Un proceso de migración administrable se define como un proceso en el que los usuarios no se ven obligados a actualizar la versión principal de la regla y la versión principal de Bazel de forma simultánea, lo que les permite controlar los cambios incompatibles de una fuente a la vez.

Por ejemplo, con la siguiente matriz de compatibilidad:

  • La migración de rules_foo 1.x + Bazel 4.x a rules_foo 2.x + Bazel 5.x no se considera administrable, ya que los usuarios deben actualizar la versión principal de rules_foo y Bazel al mismo tiempo.
  • La migración de rules_foo 2.x + Bazel 5.x a rules_foo 3.x + Bazel 6.x se considera administrable, ya que los usuarios pueden actualizar primero rules_foo de 2.x a 3.x sin cambiar la versión principal de Bazel y, luego, actualizar Bazel de 5.x a 6.x.
rules_foo 1.x rules_foo 2.x rules_foo 3.x CABEZA
Bazel 4.x ✅ ❌ ❌ ❌
Bazel 5.x ❌ ✅ ✅ ❌
Bazel 6.x ❌ ❌ ✅ ✅
CABEZA ❌ ❌ ❌ ✅

❌: Ninguna versión de la versión principal de la regla es compatible con la versión de Bazel LTS.

✅: Al menos una versión de la regla es compatible con la versión más reciente de la versión de Bazel LTS.

Prácticas recomendadas

Como autores de reglas de Bazel, puedes garantizar un proceso de migración administrable para los usuarios si sigues estas prácticas recomendadas:

  1. La regla debe seguir el control de versiones semántico: las versiones secundarias de la misma versión principal son retrocompatibles.
  2. La regla en HEAD debe ser compatible con la versión más reciente de Bazel LTS.
  3. La regla en HEAD debe ser compatible con Bazel en HEAD. Para lograrlo, puedes hacer lo siguiente:
  4. La versión principal más reciente de la regla debe ser compatible con la versión más reciente de Bazel LTS.
  5. Una versión principal nueva de la regla debe ser compatible con la última versión de Bazel LTS compatible con la versión principal anterior de la regla.

Lograr los puntos 2 y 3 es la tarea más importante, ya que permite lograr los puntos 4 y 5 de forma natural.

Para facilitar el mantenimiento de la compatibilidad con Bazel en HEAD y la versión más reciente de Bazel LTS, los autores de reglas pueden hacer lo siguiente:

  • Solicitar que las funciones retrocompatibles se transfieran a la versión más reciente de LTS Consulta el proceso de lanzamiento para obtener más detalles.
  • Usar bazel_features para realizar la detección de funciones de Bazel.

En general, con los enfoques recomendados, las reglas deberían poder migrar para los cambios incompatibles de Bazel y usar las nuevas funciones de Bazel en HEAD sin perder la compatibilidad con la versión más reciente de Bazel LTS.