Conforme anunciado na postagem original do blog (link em inglês), o Bazel 4.0 e versões mais recentes oferecem suporte a duas faixas de lançamento: versões graduais e com suporte de longo prazo (LTS). Nesta página, você verá 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 versões anteriores. 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:
- Principal: 6.0.0
- Menor: 6.1.0
- Patch: 6.1.2
- Pré-lançamento: 7.0.0-pre.20230502.1
Estágios de suporte
Há quatro estágios de suporte para cada versão principal do Bazel:
- Lançamento: essa versão principal ainda está em pré-lançamento. A equipe do Bazel publica versões contínuas do HEAD.
- Ativo: é a versão principal ativa do LTS. A equipe do Bazel faz o backport de recursos importantes e correções de bugs em versões secundárias.
- Manutenção: essa versão principal é uma versão antiga do LTS no modo de manutenção. A equipe do Bazel promete fazer backport apenas de correções de bugs críticos para problemas de segurança e de compatibilidade do SO nesta versão de LTS.
- Descontinuado: a equipe do Bazel não oferece mais suporte a essa versão principal. Todos os usuários precisam migrar para as 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
- As versões graduais são coordenadas com o lançamento do Google Blaze e são lançadas do HEAD em torno de duas semanas. É uma prévia da próxima versão do LTS do Bazel.
- As versões graduais podem enviar mudanças incompatíveis. Sinalizações incompatíveis são recomendadas para alterações interruptivas importantes. O lançamento de alterações incompatíveis precisa seguir nossa política de compatibilidade com versões anteriores.
Versões de LTS
- Versão principal: uma nova versão LTS será removida do HEAD aproximadamente a cada 12 meses. Depois que 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 de manutenção.
- Versão secundária: novas versões secundárias na faixa "Active LTS" são 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 são 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 versões planejadas, consulte nossos problemas de lançamento no GitHub.
Matriz de suporte
| Versão LTS | Estágio de suporte | Versão mais recente | Fim do suporte |
|---|---|---|---|
| Bazel 7 | Contínuo | Confira a página de versão do GitHub | N/A |
| Bazel 6 | Ativo | 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 versões (link em inglês) no GitHub.
Procedimentos e políticas de versão
Para versões graduais, o processo é simples: a cada duas semanas, uma nova versão é criada, alinhada com o mesmo valor de referência da versão Blaze interna do Google. Devido à programação de lançamento rápido, não fazemos backport de nenhuma mudança nas versões graduais.
Para versões 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 de LTS, a confirmação do valor de referência é o HEAD da ramificação principal.
- Para uma versão secundária ou de patch, a confirmação do valor de referência é o HEAD da versão mais recente atual da mesma versão do 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 por meio de PRs para a ramificação de lançamento.
- A comunidade pode sugerir que determinadas confirmações sejam transferidas por backport respondendo
"
@bazel-io flag" em problemas relevantes do GitHub ou PRs para marcá-las como possíveis bloqueadores de lançamento. A equipe do Bazel faz a triagem delas e decide se vai fazer o backport das confirmações. - Somente confirmações compatíveis com versões anteriores no branch principal podem ser feitas por backport. Outras pequenas alterações para resolver conflitos de mesclagem são aceitáveis.
- A comunidade pode sugerir que determinadas confirmações sejam transferidas por backport respondendo
"
- Identifique os obstáculos à versão e corrija os problemas encontrados na ramificação de versão.
- A ramificação de versão é 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 dos testes da ramificação de lançamento 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ão conhecidos forem resolvidos.
- O candidato a lançamento é anunciado no bazel-discuss (em inglês). A equipe do Bazel monitora os relatórios de bugs da comunidade.
- Se novos bloqueadores de versão forem identificados, volte para a ú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 a versão candidata a lançamento como oficial se nenhum outro bloqueador de versão 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 versões principais e secundárias, envie a versão 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 é publicado apenas em um dia em que o próximo é um dia útil.
- A versão é anunciada no bazel-discuss (em inglês). A equipe do Bazel monitora e aborda os relatórios de bugs da comunidade para a nova versão.
Relatar regressões
Se um usuário encontrar uma regressão em uma nova versão do Bazel, candidata a lançamento ou até mesmo no Bazel em HEAD, registre um bug no GitHub (link em inglês). Use o Bazelisk para dividir a confirmação culpa e incluir essas informações no relatório do bug.
Por exemplo, se sua versão for bem-sucedida com o Bazel 6.1.0, mas falhar com o segundo candidato a lançamento de 6.2.0, você poderá fazer a divisão usando
bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar
Você pode definir a variável de ambiente BAZELISK_SHUTDOWN ou BAZELISK_CLEAN para executar
os comandos do Bazel correspondentes a fim de redefinir o estado do build, se necessário para
reproduzir o problema. Para mais detalhes, confira a documentação sobre o
recurso bisecto do Bazelisk.
Não se esqueça de fazer upgrade do Bazelisk para a versão mais recente se quiser usar o recurso de bisecção.
Compatibilidade de regras
Se você criou uma regra e quer manter a compatibilidade com diferentes versões do Bazel, consulte a página Compatibilidade de regras (link em inglês).