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.
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:
- 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.
- 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 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.
- A comunidade pode responder para sugerir certas confirmações para backport.
"
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:
- Abra o pedido de seleção a dedo.
- 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.
- 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.
- 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 ,
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; 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?
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".