Conforme anunciado na postagem original do blog, o Bazel 4.0 e versões posteriores oferecem suporte a duas faixas de lançamento: lançamentos contínuos e suporte de longo prazo (LTS, na sigla em inglês). Nesta página, você verá as informações mais recentes sobre o modelo de lançamento do Bazel.
Controle de versão de versão
O Bazel usa um esquema de major.minor.patch controle de versão semântico.
- 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 e recursos compatíveis com versões anteriores da ramificação principal.
- Uma versão de patch contém correções críticas de bugs.
Além disso, as versões de pré-lançamento são indicadas anexando um hífen e um sufixo de data ao 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
Para cada versão principal do Bazel, há quatro estágios de suporte:
- Lançamento: esta versão principal ainda está em pré-lançamento, a equipe do Bazel publica versões contínuas de HEAD.
- Ativa: esta versão principal é a versão atual de LTS ativa. A equipe do Bazel oferece suporte a recursos importantes e correções de bugs nas versões secundárias.
- Manutenção: esta versão principal é uma versão LTS antiga no modo de manutenção. A equipe do Bazel só promete retrocompatibilidade com bugs críticos para problemas de segurança e compatibilidade com o SO nesta versão do LTS.
- Uso suspenso: 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 Bazel LTS.
Cadência de lançamento
O Bazel publica regularmente lançamentos para duas faixas de lançamento.
Lançamentos
- Os lançamentos graduais são coordenados com o lançamento do Google Blaze e lançados a partir do HEAD a cada duas semanas. Ela é uma prévia da próxima versão do Bazel LTS.
- Os lançamentos graduais podem enviar alterações incompatíveis. As sinalizações incompatíveis são recomendadas para grandes alterações interruptivas. O lançamento de alterações incompatíveis precisa seguir nossa política de compatibilidade com versões anteriores.
Lançamentos de LTS
- Versão principal: espera-se que uma nova versão LTS seja cortada do HEAD aproximadamente a cada 12 meses. Assim que uma nova versão de LTS é lançada, ela entra imediatamente no estágio Ativo, e a versão LTS anterior entra no estágio de Manutenção.
- Versão secundária: espera-se que novas versões secundárias na faixa de LTS ativa sejam lançadas uma vez a cada dois meses.
- Lançamento de patch: espera-se que novas versões de patch para versões LTS nos estágios Ativo e Manutenção sejam lançadas sob demanda para correções de bugs críticos.
- Uma versão do Bazel LTS entra no estágio obsoleto após passar dois anos no estágio de manutenção.
Para lançamentos planejados, verifique nossos problemas de versão no GitHub.
Matriz de suporte
| Versão LTS | Estágio de suporte | Versão mais recente | Fim do suporte |
|---|---|---|---|
| Bazel 7 | Contínuo | Verificar a página de lançamento do GitHub | N/A |
| Bazel 6 | Ativos | 6.3.2 | 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 (em inglês) no GitHub.
Políticas e procedimentos de lançamento
Para versões contínuas, o processo é simples: a cada duas semanas, uma nova versão é criada, alinhada à mesma linha de base da versão Blaze interna do Google. Devido à programação de lançamentos rápidos, não fazemos backport de nenhuma alteração para versões contínuas.
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 da linha de base é o HEAD da ramificação principal.
- Para uma versão secundária ou de patch, a confirmação da linha de base é o HEAD da versão mais recente atual da mesma versão LTS.
- Crie uma ramificação de lançamento no nome de
release-<version>a partir da confirmação de referência. - Mudanças de backport com PRs para a ramificação de lançamento.
- A comunidade pode sugerir que determinados confirmações sejam retroativas respondendo a "
@bazel-io flag" em problemas relevantes do GitHub ou PRs para marcá-los como possíveis obstáculos ao lançamento, a equipe do Bazel faz a triagem deles e decide se os backports serão revertidos. - Somente confirmações compatíveis com versões anteriores na ramificação principal podem ser retroativas. Outras alterações secundárias para resolver conflitos de mesclagem são aceitáveis.
- A comunidade pode sugerir que determinados confirmações sejam retroativas respondendo a "
- Identificar bloqueadores de versões e corrigir problemas encontrados na ramificação da versão.
- A ramificação de versão é testada com o mesmo conjunto de testes em pós-envio e pipeline de teste downstream no 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 de versão a partir do branch de versão quando todos os bloqueadores de versão conhecidos forem resolvidos.
- O candidato de versão é anunciado em bazel-discuss, a equipe do Bazel monitora os relatórios de bug da comunidade para o candidato.
- Se novos bloqueadores de versão forem identificados, volte para a última etapa e crie um novo candidato de versão depois de resolver todos os problemas.
- Novos recursos não podem ser adicionados ao branch de versão após a criação do primeiro candidato a lançamento.
- Enviar o candidato de versão 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 a publicação do último candidato a lançamento.
- Para as versões principais e secundárias, envie a versão dois dias úteis após a publicação do último candidato a lançamento, mas não antes de uma semana após o lançamento do primeiro candidato a lançamento.
- A versão é enviada apenas em um dia em que o dia seguinte é comercial.
- A versão é anunciada no bazel-discuss, e a equipe do Bazel monitora e aborda os relatórios de bug da comunidade para a nova versão.
Regressões de relatórios
Se um usuário encontrar uma regressão em uma nova versão do Bazel, candidato a lançamento ou até mesmo o Bazel no HEAD, registre um bug no GitHub. Você pode usar o Bazelisk para biscar a confirmação do culpado 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 de versão 6.2.0, você poderá fazer bisect via
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 para redefinir o estado do build se for necessário para reproduzir o problema. Para mais detalhes, confira a documentação sobre o recurso de bisect (em inglês) do Bazelisk.
Lembre-se de atualizar o Bazelisk para a versão mais recente para usar o recurso de bisect.
Compatibilidade da regra
Se você for autor de regras e quiser manter a compatibilidade com diferentes versões do Bazel, consulte a página Compatibilidade de regras.