Conforme anunciado na postagem do blog original, o Bazel 4.0 e as versões mais recentes oferecem suporte a duas faixas de lançamento: versões graduais e com suporte a longo prazo (LTS). Nesta página, abordamos as informações mais recentes sobre o modelo de lançamento do Bazel.
Controle de versão de lançamento
O Bazel usa um esquema de controle de versões semântico major.minor.patch.
- Uma versão principal contém recursos que não são compatíveis com a versão anterior. Cada versão principal do Bazel é uma versão LTS.
- Uma versão secundária contém correções de bugs compatíveis com versões anteriores e recursos com backport da ramificação principal.
- Uma versão de patch contém correções de bugs essenciais.
Além disso, as versões de pré-lançamento são indicadas com um hífen e um sufixo de data no próximo número da versão principal.
Por exemplo, uma nova versão de cada tipo resultaria nestes números de versão:
- Maior: 6.0.0
- Menor: 6.1.0
- Patch: 6.1.2
- Pré-lançamento: 7.0.0-pre.20230502.1
Estágios de suporte
Cada versão principal do Bazel tem quatro estágios de suporte:
- Contínuo: esta versão principal ainda está em pré-lançamento, e a equipe do Bazel publica versões graduais a partir da função HEAD.
- Ativo: esta versão principal é a versão atual do LTS ativa. A equipe do Bazel oferece suporte a recursos importantes e correções de bugs nas versões secundárias.
- Manutenção: esta é uma versão antiga do LTS no modo de manutenção. A equipe do Bazel apenas promete fazer backport de correções de bugs críticos para problemas de segurança e de compatibilidade do SO nesta versão do LTS.
- Descontinuado: a equipe do Bazel não oferece mais suporte para essa versão principal. Todos os usuários precisam migrar para versões mais recentes do LTS do Bazel.
Cadência de lançamento
O Bazel publica regularmente versões para duas faixas de lançamento.
Lançamentos contínuos
- Os lançamentos contínuos são coordenados com o lançamento do Google Blaze e são liberados do HEAD a cada duas semanas. Esta é uma prévia da próxima versão do LTS do Bazel.
- As versões contínuas podem enviar mudanças incompatíveis. Sinalizações incompatíveis são recomendadas para grandes alterações interruptivas. O lançamento de mudanças incompatíveis precisa seguir nossa política de compatibilidade com versões anteriores.
Lançamentos do LTS
- Versão principal: uma nova versão do LTS deve ser cortada do HEAD aproximadamente a cada 12 meses. Quando uma nova versão do LTS é lançada, ela entra imediatamente no estágio "Ativo", e a versão anterior do LTS entra no estágio "Manutenção".
- Versão secundária: espera-se que novas versões secundárias na faixa de LTS ativo sejam lançadas uma vez a cada dois meses.
- Versão de patch: novas versões de patch para versões LTS nos estágios Ativo e Manutenção devem ser lançadas sob demanda para correções de bugs críticos.
- Uma versão LTS do Bazel entra no estágio "Descontinuado" depois de ficar no estágio de Manutenção por dois anos.
Para lançamentos planejados, verifique nossos problemas de lançamento no GitHub.
Matriz de suporte
| Versão do LTS | Estágio de suporte | Versão mais recente | Fim do suporte |
|---|---|---|---|
| Bazel 7 | Contínuo | Conferir a página de lançamento do GitHub | N/A |
| Bazel 6 | Ativas | 6.4.0 | Dezembro de 2025 |
| Bazel 5 | Manutenção | 5.4.1 | Janeiro de 2025 |
| Bazel 4 | Manutenção | 4.2.4 | Janeiro de 2024 |
Todas as versões do Bazel podem ser encontradas na página de lançamento (link em inglês) do GitHub.
Políticas e procedimentos de lançamento
Para versões contínuas, o processo é simples: aproximadamente a cada duas semanas, uma nova versão é criada, alinhada com o mesmo valor de referência da versão interna do Google. Devido à programação de lançamento rápido, não fazemos backport de alterações em versões graduais.
Para versões de LTS, o procedimento e as políticas abaixo são seguidos:
- Determine uma confirmação de valor de referência para a versão.
- Para uma nova versão principal do LTS, a confirmação de referência é o HEAD da ramificação principal.
- Para uma versão secundária ou de patch, a confirmação de referência é o HEAD da versão mais recente da mesma versão de LTS.
- Crie uma ramificação de lançamento no nome de
release-<version>a partir da confirmação de referência. - Fazer backport das mudanças via PRs para a ramificação de lançamento.
- A comunidade pode sugerir que determinadas confirmações sejam enviadas para backport respondendo
"
@bazel-io flag" em problemas ou PRs relevantes do GitHub para marcá-los como possíveis bloqueadores de versões. A equipe do Bazel faz a triagem deles e decide se quer fazer backport das confirmações. - Somente confirmações compatíveis com versões anteriores na ramificação principal podem ter backport. Outras pequenas alterações para resolver conflitos de mesclagem são aceitáveis.
- A comunidade pode sugerir que determinadas confirmações sejam enviadas para backport respondendo
"
- Identifique os bloqueadores de versões e corrija os problemas encontrados na ramificação de versões.
- A ramificação de lançamento é testada com o mesmo pacote de testes em postsubmit e pipeline de teste downstream na CI do Bazel. A equipe do Bazel monitora os resultados de teste da ramificação de versão e corrige as regressões encontradas.
- Crie um novo candidato a lançamento na ramificação de lançamento quando todos
os bloqueadores de versões conhecidos forem resolvidos.
- A versão candidata a lançamento é anunciada no bazel-discuss (link em inglês). A equipe do Bazel monitora os relatórios de bugs da comunidade em busca do candidato.
- Se novos bloqueadores de versões forem identificados, volte à última etapa e crie um novo candidato a lançamento depois de resolver todos os problemas.
- Novos recursos não podem ser adicionados à ramificação de lançamento após a criação do primeiro candidato a lançamento.
- Envie o candidato de lançamento como a versão oficial se nenhum outro bloqueador
de lançamento for encontrado.
- Para versões de patch, envie a versão pelo menos dois dias úteis após o lançamento do último candidato a lançamento.
- Para lançamentos principais e secundários, envie dois dias úteis após o lançamento do último candidato a lançamento, mas não antes de uma semana após o lançamento do primeiro candidato a lançamento.
- O lançamento só é feito em um dia em que o dia seguinte é útil.
- A versão será anunciada no bazel-discuss (link em inglês). A equipe do Bazel monitora e aborda os relatórios de bugs da comunidade da nova versão.
Informar regressões
Se um usuário encontrar uma regressão em uma nova versão, candidato a lançamento ou até mesmo o Bazel em HEAD, registre um bug no GitHub. Você pode usar o Bazelisk para dividir a confirmação do culpado e incluir essas informações no relatório do bug.
Por exemplo, se a versão for bem-sucedida com o Bazel 6.1.0, mas falhar com a segunda versão candidata a lançamento, a 6.2.0, será possível fazer a bissecção por meio de
bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar
É possível definir a variável de ambiente BAZELISK_SHUTDOWN ou BAZELISK_CLEAN para executar
comandos do Bazel correspondentes a fim de redefinir o estado do build, se necessário para
reproduzir o problema. Para mais detalhes, consulte a documentação sobre o
recurso bisect do Bazelisk.
Faça upgrade do Bazelisk para a versão mais recente para usar o recurso de bisect.
Compatibilidade de regras
Se você é autor de regras e quer manter a compatibilidade com diferentes versões do Bazel, consulte a página Compatibilidade de regras.