En esta página, se proporciona información para controlar la retrocompatibilidad, incluida la migración de una versión a otra, y la comunicación de cambios incompatibles.
Bazel está evolucionando. Las versiones secundarias publicadas como parte de una versión principal de LTS tienen retrocompatibilidad. Las nuevas versiones principales de LTS pueden contener cambios incompatibles que requieren un esfuerzo de migración. Para obtener más información sobre el modelo de lanzamiento de Bazel, consulta la página Modelo de versión.
Resumen
- Se recomienda usar marcas
--incompatible_*para realizar cambios rotundos. - Para cada marca
--incompatible_*, un problema de GitHub explica el cambio en el comportamiento y tiene como objetivo proporcionar una receta de migración. - Se recomienda que las marcas incompatibles sean compatibles con la última versión de LTS sin habilitar la marca de forma predeterminada.
- Las APIs y el comportamiento protegidos por una marca
--experimental_*pueden cambiar en cualquier momento. - Nunca ejecutes compilaciones de producción con las marcas
--experimental_*o--incompatible_*.
Cómo seguir esta política
- Para usuarios de Bazel: cómo actualizar Bazel
- Para colaboradores: Prácticas recomendadas para cambios incompatibles
- Para los administradores de versiones: Cómo actualizar las etiquetas de problemas y los lanzamientos
¿Qué es la funcionalidad estable?
En general, las APIs o los comportamientos sin marcas de --experimental_... se consideran
funciones compatibles y estables en Bazel.
Esto incluye lo siguiente:
- Lenguaje y API de Starlark
- Conjuntos de reglas con Bazel
- API de Bazel, como las API de Remote Execution o el protocolo de eventos de compilación
- Marcas y su semántica
Cambios incompatibles y recetas de migración
Por cada cambio incompatible en una versión nueva, el equipo de Bazel busca proporcionar una
receta de migración que te ayude a actualizar tu código (archivos BUILD y .bzl, además de cualquier uso de Bazel en secuencias de comandos, el uso de la API de Bazel, etcétera).
Los cambios incompatibles deben tener una marca de --incompatible_* asociada y un problema de GitHub correspondiente.
Se recomienda que la marca incompatible y los cambios relevantes sean portabilidad a versiones anteriores a la versión LTS más reciente sin habilitarla de forma predeterminada. Esto permite que los usuarios migren los cambios incompatibles antes de que la próxima versión LTS esté disponible.
Cómo comunicar cambios incompatibles
La fuente principal de información sobre los cambios incompatibles son los problemas de GitHub marcados con una etiqueta"incompatible-change".
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 HEAD
(por lo tanto, con la próxima versión progresiva de Bazel), se debe marcar con
la etiqueta migration-ready. El problema de cambio incompatible se cierra cuando la marca incompatible se gira en HEAD.