Modelo de lançamento

Informar um problema Conferir origem Por 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.

Matriz de suporte

Versão do LTS	Estágio de suporte	Versão mais recente	Fim do suporte
Bazel 8	Contínuo	Conferir a página de lançamento gradual	N/A
Bazel 7	Ativo	7.3.0	Dezembro de 2026
Bazel 6	Manutenção	6.5.0	Dezembro de 2025
Bazel 5	Manutenção	5.4.1	Janeiro de 2025
Bazel 4	Suspenso	4.2.4	Janeiro de 2024

Todas as versões LTS do Bazel podem ser encontradas na versão página (link em inglês) no GitHub.

Observação :as versões do Bazel mais antigas que a Bazel 5 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.

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.

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. Mudanças de backport usando um problema de solicitação Cherry-Pick para mantenedores do Bazel.

   • Os mantenedores do Bazel podem solicitar a seleção de confirmações específicas. para uma ramificação de lançamento. Esse processo é iniciado com a criação a cherry-pick no GitHub. É muito fácil:

     1. Abra o pedido de seleção a dedo.
     2. Preencha os detalhes da solicitação
        • Título: forneça um título conciso e descritivo para a solicitação.
        • IDs de commit: insira os IDs das confirmações que você quer a dedo. Se houver várias confirmações, separe por vírgulas.
        • Categoria: especifique a categoria da solicitação.
        • Revisor(es): se houver vários revisores, separe os deles no GitHub IDs com vírgulas.
     3. Defina a meta
        • Encontre o "Marco" e clique na configuração.
        • Selecione os bloqueadores de lançamento X.Y.Z apropriados. Esta ação aciona o bot de seleção para processar sua solicitação para "release-X.Y.Z" ramificação.
     4. Enviar o problema
        • Depois de preencher todos os detalhes e definir a meta, envie o problema.

   • O bot de seleção vai processar a solicitação e notificar se as confirmações estiverem qualificadas para a seleção. Se os commits são selecionáveis a dedo, o que significa que não conflitos de mesclagem enquanto seleciona a confirmação, e o bot vai criar uma nova solicitação de envio. Quando a atração seja aprovada por um membro da equipe do Bazel, o as confirmações são escolhidas a dedo e mescladas à ramificação de lançamento. Para um exemplo visual de uma solicitação de seleção concluída, consulte este exemplo ,

5. 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.

6. 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; acervos são limitados a itens críticos somente correções. Se você precisar de uma palheta, o solicitante precisará responder à perguntas a seguir: por que essa mudança é crítica e quais benefícios que ele oferece? Qual é a probabilidade dessa mudança introduzir uma regressão?

7. 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".