Esta página fornece informações sobre como lidar com a compatibilidade com versões anteriores, incluindo a migração de uma versão para outra e como se comunicar alterações incompatíveis.
O Bazel está evoluindo. Versões secundárias lançadas como parte de um LTS principal version são totalmente compatíveis com versões anteriores. Novo LTS principal podem conter alterações incompatíveis que exigem algum esforço de migração. Para mais informações sobre o modelo de versão do Bazel, consulte a documentação Modelo.
Resumo
- É recomendável usar as sinalizações
--incompatible_*para alterações interruptivas. - Para cada flag
--incompatible_*, um problema do GitHub explica a alteração em comportamento do cliente e tem como objetivo fornecer um roteiro de migração. - É recomendável fazer a retrocompatibilidade de sinalizações incompatíveis para o LTS mais recente sem ativar a sinalização por padrão.
- As APIs e o comportamento protegidos por uma flag
--experimental_*podem mudar a qualquer tempo de resposta. - Nunca execute builds de produção com
--experimental_*ou--incompatible_*. de status.
Como seguir esta política
- Para usuários do Bazel: como atualizar o Bazel
- Para colaboradores: práticas recomendadas para mudanças incompatíveis
- Para os administradores da versão: como atualizar os rótulos de problemas e a versão
O que é uma funcionalidade estável?
Em geral, APIs ou comportamentos sem flags --experimental_... são considerados
recursos estáveis compatíveis com o Bazel.
Isso inclui:
- Linguagem e APIs Starlark
- Regras empacotadas com o Bazel
- APIs do Bazel, como as APIs Remote Execution ou o Build Event Protocol
- Sinalizações e semânticas
Mudanças incompatíveis e roteiros de migração
Para cada mudança incompatível em uma nova versão, a equipe do Bazel tem como objetivo fornecer uma
roteiro de migração que ajuda você a atualizar seu código (arquivos BUILD e .bzl, conforme
bem como qualquer uso do Bazel em scripts, uso da API Bazel e assim por diante).
As mudanças incompatíveis precisam ter uma flag --incompatible_* associada e um
problema correspondente no GitHub.
É recomendável fazer a retrocompatibilidade da flag incompatível e das alterações relevantes para a versão mais recente do LTS sem ativar a flag por padrão. Isso permite que os usuários migrar para as mudanças incompatíveis antes que a próxima versão do LTS seja disponíveis.
Comunicação de mudanças incompatíveis
A principal fonte de informações sobre mudanças incompatíveis são problemas do GitHub marcado com "incompatível-alteração" rótulo.
Para cada alteração incompatível, o problema especifica o seguinte:
- Nome do flag que controla a alteração incompatível
- Descrição da funcionalidade alterada
- Roteiro de migração
Quando uma mudança incompatível estiver pronta para migração com o Bazel em HEAD
(portanto, também com a próxima versão gradual do Bazel), ela será marcada com
o rótulo migration-ready. O problema de alteração incompatível é encerrado quando a
flag incompatível seja invertida em HEAD.