Modelo de lançamento

Informar um problema Mostrar fonte Noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

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 as principais alterações interruptivas, com o 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.

Observação :as versões do Bazel mais antigas que a 4 não são mais compatíveis, os usuários do Bazel são faça upgrade para a versão mais recente do LTS ou use versões graduais se quero ficar por dentro das mudanças mais recentes na seção HEAD.

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:

1. Determine uma confirmação de valor de referência para a versão.
   • Para uma nova versão principal de 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.
2. Crie uma ramificação de versão no nome de release-<version> com base no valor de referência fazer commit.
3. 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 versões, a equipe do Bazel faz a triagem deles e decide 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.
4. 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.
5. 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.
6. 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".