Como anunciado na postagem original do blog, o Bazel 4.0 e as versões mais recentes oferecem suporte a duas faixas de lançamento: lançamentos graduais 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 uma string major.minor.patch semântica controle de versões.
- Uma versão principal contém recursos que não são compatíveis com versões anteriores da 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. com backport 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 sinal de sufixo de data para o 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
Para cada versão principal do Bazel, há quatro estágios de suporte:
- Rolling: essa versão principal ainda está em pré-lançamento. A equipe do Bazel publica lançamentos contínuos do HEAD.
- Ativo: essa versão principal é a versão LTS ativa atual. O Bazel oferece backport de recursos importantes e correções de bugs em seus lançamentos menores.
- Manutenção: esta versão principal é uma versão antiga do LTS em manutenção. modo A equipe do Bazel só promete fazer a backport de correções de bugs críticas para problemas de segurança e de compatibilidade do SO nesta versão LTS.
- Descontinuado: a equipe do Bazel não oferece mais suporte a essa versão principal. Todos os usuários precisam migrar para versões mais recentes do Bazel LTS.
Cadência de lançamento
O Bazel publica versões regularmente 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 lançados de HEAD, aproximadamente, a cada duas semanas. É uma prévia do próximo LTS do Bazel lançamento.
- As versões graduais podem enviar mudanças incompatíveis. As flags incompatíveis são recomendadas para mudanças importantes, e o lançamento de mudanças incompatíveis deve seguir nossa política de compatibilidade reversa.
Lançamentos do LTS
- Versão principal: uma nova versão do LTS deve ser cortada aproximadamente do HEAD. todo(a) 12 meses. Quando uma nova versão do LTS é lançada, ela entra imediatamente no estado e a versão anterior do LTS entra no estágio de manutenção.
- Versão secundária: espera-se que novas versões secundárias na faixa LTS ativa sejam ser lançada uma vez a cada 2 meses.
- Versão do 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 de descontinuação depois de ficar no estágio de manutenção por dois anos.
Para lançamentos programados, consulte 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çamentos 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çamentos do GitHub.
Procedimento de liberação e políticas
Para lançamentos contínuos, o processo é simples: a cada duas semanas, uma nova versão é criada, alinhada com a mesma linha de base do lançamento Blaze interno do Google. Devido à programação de lançamento rápido, não faremos backport de nenhuma mudança para lançamentos 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 do principal ramificação.
- Para uma versão secundária ou de patch, a confirmação de referência é o HEAD do a versão mais recente do mesmo LTS.
- Crie uma ramificação de lançamento com o nome
release-<version>a partir do commit de referência. - Faça a retrocompatibilidade de mudanças por meio de PRs na ramificação de lançamento.
- A comunidade pode sugerir que determinadas confirmações sejam enviadas de volta respondendo
"
@bazel-io flag" em problemas ou PRs relevantes do GitHub para marcá-las como possíveis bloqueadores de lançamento. A equipe do Bazel faz a triagem e decide se vai enviar as confirmações de volta. - Somente confirmações compatíveis com versões anteriores na ramificação principal podem ter backport, são aceitáveis alterações pequenas adicionais para resolver conflitos de integração.
- A comunidade pode sugerir que determinadas confirmações sejam enviadas de volta 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 postsubmit e pipeline de teste downstream no Bazel CI. A equipe do Bazel monitora os resultados dos testes da versão. e corrige as regressões encontradas.
- Criar um novo candidato a lançamento da ramificação de lançamento quando todos os elementos conhecidos
que os bloqueadores de lançamento
sejam resolvidos.
- O candidato à versão é anunciado no 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 à versão depois de resolver todos os problemas.
- Novos recursos não podem ser adicionados à ramificação da versão após a a primeira versão candidata a lançamento seja criada.
- Enviar a versão candidata 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 última versão candidata.
- Para lançamentos principais e secundários, envie dois dias úteis depois o último candidato a lançamento foi removido, mas não menos de uma semana depois o primeiro candidato a lançamento já está disponível.
- O lançamento só é feito em um dia em que o dia seguinte é um negócio. dia.
- O lançamento é anunciado em bazel-discuss, a equipe do Bazel monitora e aborda 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, a versão candidata a lançamento ou mesmo Bazel em HEAD, informe um bug em GitHub. Você pode usar o Bazelisk para bisseccionar a confirmação do culpado e incluir essas informações no relatório de bugs.
Por exemplo, se sua versão for bem-sucedida com o Bazel 6.1.0, mas falhar na segunda candidata a lançamento da versão 6.2.0, poderá fazer a bissecção
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 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 de bisset do Bazelisk.
Para usar a bisect, faça upgrade do Bazelisk para a versão mais recente .
Compatibilidade de regras
Se você cria regras e quer manter a compatibilidade com diferentes para outras versões do Bazel. Confira a Regras página "Compatibilidade".