Retrocompatibilidad

Informar un problema Ver fuente . Por la noche · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

En esta página, se proporciona información sobre cómo controlar la retrocompatibilidad incluida la migración de una versión a otra y cómo comunicar cambios incompatibles.

Bazel está evolucionando. Versiones secundarias lanzadas como parte de un principal de LTS versión son totalmente retrocompatibles. Nueva LTS importante y las versiones pueden contener cambios incompatibles que requieran cierto esfuerzo de migración. Para obtener más información sobre el modelo de lanzamiento de Bazel, consulta la versión Modelo.

Resumen

  1. Se recomienda usar las marcas --incompatible_* para los cambios rotundos.
  2. Por cada marca --incompatible_*, un problema de GitHub explica el cambio en y su objetivo es proporcionar una receta de migración.
  3. Se recomienda que las marcas incompatibles se transfieran a la versión más reciente de LTS sin habilitar la marca de forma predeterminada.
  4. Las APIs y el comportamiento protegidos por una marca --experimental_* pueden cambiar en cualquier tiempo.
  5. Nunca ejecutes compilaciones de producción con --experimental_* o --incompatible_*. marcas.

Cómo cumplir con esta política

¿Qué es una funcionalidad estable?

En general, las APIs o los comportamientos sin marcas --experimental_... se consideran funciones compatibles y estables en Bazel.

Esto incluye lo siguiente:

  • Lenguaje y APIs de Starlark
  • Reglas agrupadas con Bazel
  • APIs de Bazel, como las APIs de ejecución remota o el protocolo de eventos de compilación
  • Marcas y su semántica

Cambios y recetas de migración incompatibles

Por cada cambio incompatible en una nueva versión, el equipo de Bazel tiene como objetivo proporcionar un receta de migración que te ayuda a actualizar tu código (archivos BUILD y .bzl, como así como cualquier uso de Bazel en secuencias de comandos, uso de la API de Bazel, etc.).

Los cambios incompatibles deben tener una marca --incompatible_* asociada y una correspondiente a GitHub.

Se recomienda la portabilidad a versiones anteriores de la marca incompatible y los cambios relevantes la última versión de LTS sin habilitar la marca de forma predeterminada. Esto permite que los usuarios migrar en busca de los cambios incompatibles antes de que la próxima versión de LTS disponibles.

Cómo comunicar cambios incompatibles

La fuente principal de información sobre cambios incompatibles son los problemas de GitHub está marcado con un "incompatible-change" etiqueta.

Para cada cambio incompatible, el problema especifica lo siguiente:

  • Nombre de la marca que controla el cambio incompatible
  • Descripción de la funcionalidad modificada
  • Receta de migración

Cuando un cambio incompatible está listo para la migración con Bazel en el encabezado (por lo tanto, también en la próxima versión progresiva de Bazel), se debe marcar con la etiqueta migration-ready El problema de cambio incompatible se cierra cuando marca incompatible se lanza en el encabezado.