Conforme anunciado no blog original post, Bazel As versões 4.0 e superiores são compatíveis com duas faixas de lançamento: e de suporte de longo prazo (LTS). Nesta página, abordamos os tópicos mais recentes informações 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 as para 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. 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 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
Cada versão principal do Bazel tem quatro estágios de suporte:
- Lançamento: esta versão principal ainda está em pré-lançamento, a equipe do Bazel publica lançamentos contínuos do HEAD.
- Ativo: esta versão principal é a versão atual do LTS ativa. 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 backport de correções de bugs essenciais para problemas de segurança e de compatibilidade do SO para essa versão do LTS.
- Descontinuado: a equipe do Bazel não oferece mais suporte a esta versão principal. todos os usuários devem 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
- 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 contínuas podem enviar mudanças incompatíveis. As sinalizações incompatíveis são recomendado para grandes alterações interruptivas, com lançamento de alterações incompatíveis deve seguir nossa compatibilidade com versões anteriores política.
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 de patch: novas versões de patch para versões de LTS nas faixas Ativa e As etapas de manutenção devem ser lançadas sob demanda para bugs críticos e correções.
- Uma versão LTS do Bazel entra no estágio "Descontinuado" depois de estar no Estágio de manutenção por 2 anos.
Para lançamentos planejados, confira nossas versões problemas 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 | 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 (link em inglês) no GitHub.
Procedimento de liberação e políticas
Para lançamentos contínuos, o processo é simples: aproximadamente a cada duas semanas, um uma nova versão é criada, se alinhando com o mesmo valor de referência do Lançamento Blaze. Devido à programação de lançamento rápido, não faremos backport de nenhuma mudança até 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 versão no nome de
release-<version>
com base no valor de referência fazer commit. - Fazer backport das mudanças via PRs para a ramificação de lançamento.
- A comunidade pode responder para sugerir certas confirmações para backport.
"
@bazel-io flag
" sobre problemas relevantes do GitHub ou PRs para marcá-los como possíveis os bloqueadores de lançamento, a equipe do Bazel faz a triagem deles e decide se precisa fazer backport dos commits. - 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 responder para sugerir certas confirmações para backport.
"
- 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 bloqueios de lançamento
sejam resolvidos.
- O candidato a lançamento é anunciado bazel-discuss (em inglês) a equipe do Bazel monitora os relatórios de bugs da comunidade do candidato.
- Se novos bloqueadores de lançamento forem identificados, volte à última etapa e criar um novo candidato a lançamento 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.
- Promova a versão candidata a lançamento como a versão oficial caso não haja mais lançamentos
bloqueadores são encontrados
- Para versões de patch, envie a versão pelo menos dois dias úteis após o último candidato a lançamento já está disponível.
- 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 será anunciado em bazel-discuss (em inglês) a equipe do Bazel monitora e lida com os relatórios de bugs da comunidade para a lançamento.
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 precisa separar a confirmação do culpado e incluir essas informações no bug. no relatório.
Por exemplo, se a 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, é possível 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 correspondentes do Bazel para redefinir o estado do build, caso necessário
reproduzir o problema. Para mais detalhes, confira a documentação sobre o Bazelisk
recurso bisect.
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".