Conforme anunciado na postagem original do blog, o Bazel 4.0 e versões mais recentes oferecem suporte a duas linhas de lançamento: lançamentos contínuos e de suporte de longo prazo (LTS). Esta página aborda 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 é um lançamento LTS.
- Uma versão secundária contém correções de bugs e recursos compatíveis com versões anteriores portados da ramificação principal.
- Uma versão de patch contém correções de bugs críticos.
Além disso, as versões de pré-lançamento são indicadas com um hífen e um sufixo de data anexados ao próximo número de versão principal.
Por exemplo, uma nova versão de cada tipo resultaria nestes números de versão:
- Principal: 6.0.0
- Secundária: 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:
- Rolling: esta versão principal ainda está em pré-lançamento, e a equipe do Bazel publica versões rolling do HEAD.
- Ativa: esta versão principal é a versão LTS ativa atual. A equipe do Bazel faz o backport de recursos importantes e correções de bugs nas versões secundárias.
- Manutenção: esta versão principal é uma versão LTS antiga em modo de manutenção. A equipe do Bazel promete fazer o backport de correções de bugs críticos para problemas de segurança e de compatibilidade com o SO nessa versão LTS.
- Descontinuado: a equipe do Bazel não oferece mais suporte a esta versão principal. Todos os usuários precisam migrar para versões LTS mais recentes do Bazel.
Cadência de lançamento
O Bazel publica regularmente lançamentos para duas faixas de lançamento.
Lançamentos graduais
- Os lançamentos contínuos são coordenados com o lançamento do Google Blaze e são disponibilizados do HEAD a cada duas semanas. É uma prévia da próxima versão do Bazel LTS.
- Os lançamentos graduais podem enviar mudanças incompatíveis. As flags incompatíveis são recomendadas para grandes mudanças incompatíveis. A implantação de mudanças incompatíveis precisa seguir nossa política de compatibilidade com versões anteriores.
Versões LTS
- Versão principal: uma nova versão LTS será lançada do HEAD aproximadamente a cada 12 meses. Quando uma nova versão LTS é lançada, ela entra imediatamente na fase "Ativa", e a versão LTS anterior entra na fase "Manutenção".
- Versão secundária: novas versões secundárias na faixa do LTS ativo devem ser lançadas a cada dois meses.
- Versão de patch: novas versões de patch para versões LTS nas etapas ativa e de manutenção devem ser lançadas sob demanda para correções de bugs críticos.
- Uma versão LTS do Bazel entra na fase de descontinuação depois de ficar na fase de manutenção por dois anos.
Para versões planejadas, confira 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 lançamento 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 lançamento no GitHub.
Procedimento e políticas de lançamento
Para lançamentos contínuos, o processo é simples: a cada duas semanas, aproximadamente, um novo lançamento é criado, alinhado com a mesma base do lançamento interno do Blaze do Google. Devido ao cronograma de lançamento rápido, não fazemos backport de nenhuma mudança para lançamentos contínuos.
Para versões LTS, o procedimento e as políticas abaixo são seguidos:
- Determine um commit de base para a versão.
- Para uma nova versão LTS principal, o commit de base é o HEAD da ramificação principal.
- Para uma versão secundária ou de patch, o commit de base é o HEAD da versão mais recente atual da mesma versão LTS.
- Crie uma ramificação de lançamento com o nome
release-<version>do commit de referência. - Fazer backport de mudanças via PRs para a ramificação de lançamento.
- A comunidade pode sugerir determinados commits para serem portados para versões anteriores respondendo "
@bazel-io flag" em problemas ou solicitações de pull relevantes do GitHub para marcá-los como possíveis bloqueadores de lançamento. A equipe do Bazel os classifica e decide se vai fazer a portabilidade para versões anteriores. - Somente commits compatíveis com versões anteriores na ramificação principal podem ser portados para versões anteriores. Pequenas mudanças adicionais para resolver conflitos de mesclagem são aceitáveis.
- A comunidade pode sugerir determinados commits para serem portados para versões anteriores respondendo "
- Identifique bloqueadores de lançamento e corrija problemas encontrados na ramificação de lançamento.
- A ramificação de lançamento é testada com o mesmo pacote de testes em postsubmit e pipeline de teste downstream no Bazel CI. 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 lançamento conhecidos forem resolvidos.
- O candidato a lançamento é anunciado em bazel-discuss, e a equipe do Bazel monitora os relatórios de bugs da comunidade para o candidato.
- Se novos bloqueadores de lançamento forem identificados, volte à última etapa e crie um novo candidato a lançamento depois de resolver todos os problemas.
- Não é permitido adicionar novos recursos à ramificação de lançamento depois que o primeiro candidato a lançamento é criado.
- Envie a versão candidata como o lançamento oficial se não forem encontrados mais bloqueadores de lançamento.
- Para lançamentos de patch, faça o push pelo menos dois dias úteis depois que o último candidato a lançamento for disponibilizado.
- Para lançamentos principais e secundários, envie o lançamento dois dias úteis após a última versão candidata, mas não antes de uma semana após a primeira versão candidata.
- A versão só é enviada em um dia em que o dia seguinte é útil.
- O lançamento é anunciado em bazel-discuss, e a equipe do Bazel monitora e resolve os relatórios de bugs da comunidade para a nova versão.
Informar regressões
Se um usuário encontrar uma regressão em uma nova versão do Bazel, um candidato a lançamento ou até mesmo o Bazel no HEAD, registre um bug no GitHub. Use o Bazelisk para dividir o commit causador do problema e inclua essas informações no relatório de bug.
Por exemplo, se o build for bem-sucedido com o Bazel 6.1.0, mas falhar com o segundo candidato a lançamento do 6.2.0, você poderá fazer a bissecção usando
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
os comandos do bazel correspondentes e 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.
Não se esqueça de atualizar o Bazelisk para a versão mais recente e usar o recurso bisect.
Compatibilidade de regras
Se você cria regras e quer manter a compatibilidade com diferentes versões do Bazel, confira a página Compatibilidade de regras.