En esta página, se proporciona información para controlar la retrocompatibilidad, lo que incluye la migración de una versión a otra y cómo comunicar cambios incompatibles.
Bazel está evolucionando. Las versiones secundarias publicadas como parte de una versión principal de LTS son totalmente retrocompatibles. Las versiones principales de LTS nuevas pueden contener cambios incompatibles que requieren cierto esfuerzo de migración. Para obtener más información sobre el modelo de lanzamiento de Bazel, consulta la página Modelo de lanzamiento.
Resumen
- Se recomienda usar las marcas
--incompatible_*para los 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 se transfieran a 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 cumplir con esta política
- Para usuarios de Bazel: cómo actualizar Bazel
- Para colaboradores: prácticas recomendadas para cambios incompatibles
- Para administradores de versiones: Cómo actualizar las etiquetas de problemas y las versiones
¿Qué es una funcionalidad estable?
En general, las APIs o los comportamientos sin marcas --experimental_... se consideran
funciones estables y compatibles con 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
Para cada cambio incompatible en una nueva versión, el equipo de Bazel tiene como objetivo proporcionar una
receta de migración que te ayude a actualizar el código (archivos BUILD y .bzl, así como cualquier uso de Bazel en secuencias de comandos, uso de la API de Bazel, etcétera).
Los cambios incompatibles deben tener una marca --incompatible_* asociada y un problema de GitHub correspondiente.
Se recomienda que la marca incompatible y los cambios relevantes se porten a la versión más reciente de LTS sin habilitar la marca de forma predeterminada. Esto permite que los usuarios migren para los cambios incompatibles antes de que la próxima versión con 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 de “cambio incompatible”.
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 migrar con Bazel en el encabezado (por lo tanto, también 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 el encabezado.