Conforme anunciado na postagem do blog original, o Bazel 4.0 e as versões mais recentes oferecem suporte a duas faixas de lançamento: versões graduais e com suporte a longo prazo (LTS). Nesta página, abordamos as informações mais recentes 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 | Ativas | 7.2.1 | 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 | Descontinuado | 4.2.4 | Janeiro de 2024 |
Todas as versões LTS do Bazel podem ser encontradas na página de lançamento (link em inglês) do GitHub.
Controle de versão de lançamento
O Bazel usa um esquema de controle de versões semântico major.minor.patch.
- Uma versão principal contém recursos que não são compatíveis com 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 compatíveis com versões anteriores e recursos 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 sufixo de data no 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:
- Contínuo: esta versão principal ainda está em pré-lançamento, e a equipe do Bazel publica versões graduais a partir da função HEAD.
- Ativo: esta versão principal é a versão atual do LTS ativa. A equipe do Bazel oferece suporte a recursos importantes e correções de bugs nas versões secundárias.
- Manutenção: esta é uma versão antiga do LTS no modo de manutenção. A equipe do Bazel apenas promete fazer backport de correções de bugs críticos para problemas de segurança e de compatibilidade do SO nesta versão do LTS.
- Descontinuado: a equipe do Bazel não oferece mais suporte para essa versão principal. Todos os usuários precisam migrar para 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
- Os lançamentos contínuos são coordenados com o lançamento do Google Blaze e são liberados do HEAD a cada duas semanas. Esta é uma prévia da próxima versão do LTS do Bazel.
- As versões contínuas podem enviar mudanças incompatíveis. Sinalizações incompatíveis são recomendadas para grandes alterações interruptivas. O lançamento de mudanças incompatíveis precisa seguir nossa política de compatibilidade com versões anteriores.
Lançamentos do LTS
- Versão principal: uma nova versão do LTS deve ser cortada do HEAD aproximadamente a cada 12 meses. Quando uma nova versão do LTS é lançada, ela entra imediatamente no estágio "Ativo", e a versão anterior do LTS entra no estágio "Manutenção".
- Versão secundária: espera-se que novas versões secundárias na faixa de LTS ativo sejam lançadas uma vez a cada dois meses.
- Versão de 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 "Descontinuado" depois de ficar no estágio de Manutenção por dois anos.
Para lançamentos planejados, verifique nossos problemas de lançamento no GitHub.
Políticas e procedimentos de lançamento
Para versões contínuas, o processo é simples: aproximadamente a cada duas semanas, uma nova versão é criada, alinhada com o mesmo valor de referência da versão interna do Google. Devido à programação de lançamento rápido, não fazemos backport de alterações em versões 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 da ramificação principal.
- Para uma versão secundária ou de patch, a confirmação de referência é o HEAD da versão mais recente da mesma versão de LTS.
- Crie uma ramificação de lançamento no nome de
release-<version>
a partir da confirmação de referência. - Fazer backport das mudanças via PRs para a ramificação de lançamento.
- A comunidade pode sugerir que determinadas confirmações sejam enviadas para backport respondendo
"
@bazel-io flag
" em problemas ou PRs relevantes do GitHub para marcá-los como possíveis bloqueadores de versões. A equipe do Bazel faz a triagem deles e decide se quer fazer backport das confirmações. - Somente confirmações compatíveis com versões anteriores na ramificação principal podem ter backport. Outras pequenas alterações para resolver conflitos de mesclagem são aceitáveis.
- A comunidade pode sugerir que determinadas confirmações sejam enviadas para backport respondendo
"
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 de uma solicitação de escolha 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 selecionar. Se houver várias confirmações, separe-as por vírgulas.
- Categoria: especifique a categoria da solicitação.
- Revisores: no caso de vários revisores, separe os IDs do GitHub por vírgulas.
- Defina o marco
- Encontre a seção "Marco" e clique na configuração.
- Selecione os bloqueadores de lançamento X.Y.Z apropriados. Essa ação aciona o bot de seleção para processar sua solicitação para a ramificação "release-X.Y.Z".
- Envie o problema.
- Depois de preencher todos os detalhes e definir o metadado, envie o problema.
O bot de seleção processará a solicitação e notificará se as confirmações estiverem qualificadas para a seleção. Se as confirmações forem selecionáveis a dedo, o que significa que não há conflito de mesclagem durante a seleção, o bot criará uma nova solicitação de envio. Quando a solicitação de envio é aprovada por um membro da equipe do Bazel, as confirmações são escolhidas a dedo e mescladas na ramificação de lançamento. Para um exemplo visual de uma solicitação de seleção completa, 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 em postsubmit e pipeline de teste downstream na CI do Bazel. A equipe do Bazel monitora os resultados de teste da ramificação de versão e corrige as regressões encontradas.
Crie um novo candidato a lançamento na ramificação de lançamento quando todos os bloqueadores de versões conhecidos forem resolvidos.
- A versão candidata a lançamento é anunciada no bazel-discuss (link em inglês). A equipe do Bazel monitora os relatórios de bugs da comunidade em busca do candidato.
- Se novos bloqueadores de versões forem identificados, volte à última etapa e crie um novo candidato a lançamento depois de resolver todos os problemas.
- Novos recursos não podem ser adicionados à ramificação de versão após a criação do primeiro candidato a lançamento. As seleções são limitadas apenas a correções críticas. Se for necessária uma escolha, o solicitante precisará responder às seguintes perguntas: por que essa mudança é crítica e quais benefícios ela oferece? Qual é a probabilidade de essa mudança introduzir uma regressão?
Envie o candidato de lançamento 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 o lançamento do último candidato a lançamento.
- Para lançamentos principais e secundários, envie dois dias úteis após o lançamento do último candidato a lançamento, mas não antes de uma semana após o lançamento do primeiro candidato a lançamento.
- O lançamento só é feito em um dia em que o dia seguinte é útil.
- A versão será anunciada no bazel-discuss (link em inglês). A equipe do Bazel monitora e aborda os relatórios de bugs da comunidade da nova versão.
Informar regressões
Se um usuário encontrar uma regressão em uma nova versão, candidato a lançamento ou até mesmo o Bazel em HEAD, registre um bug no GitHub. Você pode usar o Bazelisk para dividir a confirmação do culpado e incluir essas informações no relatório do bug.
Por exemplo, se a versão for bem-sucedida com o Bazel 6.1.0, mas falhar com a segunda versão candidata a lançamento, a 6.2.0, será possível fazer a bissecção por meio de
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 do Bazel correspondentes a fim de redefinir o estado do build, se necessário para
reproduzir o problema. Para mais detalhes, consulte a documentação sobre o
recurso bisect do Bazelisk.
Faça upgrade do Bazelisk para a versão mais recente para usar o recurso de bisect.
Compatibilidade de regras
Se você é autor de regras e quer manter a compatibilidade com diferentes versões do Bazel, consulte a página Compatibilidade de regras.