Modelo de lançamento

Informar um problema Acessar fonte

Conforme anunciado na postagem original do blog (link em inglês), o Bazel 4.0 e as versões mais recentes oferecem suporte a duas faixas de lançamento: versões graduais e versões com suporte de longo prazo (LTS, na sigla em inglês). Nesta página, abordamos as informações mais recentes sobre o modelo de lançamento do Bazel.

Matriz de suporte

Versão LTS Estágio de suporte Versão mais recente Fim do suporte
Bazel 8 Contínuo Verificar a página da versão gradual N/A
Bazel 7 Ativo 7.1.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 versões (link em inglês) no 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 ao 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

Há quatro estágios de suporte para cada versão principal do Bazel:

  • Contínua: esta versão principal ainda está em pré-lançamento. A equipe do Bazel publica versões graduais do HEAD.
  • Ativa: esta versão principal é a versão ativa do LTS no momento. A equipe do Bazel faz o backport de recursos e correções de bugs importantes nas versões secundárias.
  • Manutenção: esta versão principal é uma antiga versão LTS no modo de manutenção. A equipe do Bazel promete apenas fazer o 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 a essa versão principal. Todos os usuários precisam 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

  • As versões graduais são coordenadas com a versão do Google Blaze e são lançadas do HEAD a cada duas semanas. É uma prévia da próxima versão do LTS do Bazel.
  • As versões graduais podem enviar alterações incompatíveis. Sinalizações incompatíveis são recomendadas para grandes alterações interruptivas. O lançamento de alterações incompatíveis precisa seguir nossa política de compatibilidade com versões anteriores.

Versões de LTS

  • Lançamento principal: espera-se que uma nova versão LTS seja removida do HEAD aproximadamente a cada 12 meses. Depois que 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: novas versões secundárias na faixa do LTS ativo precisam ser 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íticas.
  • Uma versão LTS do Bazel entra no estágio "Descontinuado" depois de ficar no estágio de manutenção por dois anos.

Para versões planejadas, consulte nossos problemas de lançamento no GitHub.

Procedimentos e políticas de liberação

Para versões graduais, o processo é simples: a cada duas semanas, uma nova versão é criada, alinhada com o mesmo valor de referência da versão interna do Google Blaze. Devido à programação de lançamentos rápidos, não fazemos backport de nenhuma alteração em versões graduais.

Para versões LTS, o procedimento e as políticas abaixo são seguidos:

  1. Determine uma confirmação de referência para o lançamento.
    • Para uma nova versão principal do LTS, a confirmação do valor de referência é o HEAD do branch principal.
    • Para uma versão secundária ou de patch, a confirmação do valor de referência é a HEAD da versão atual mais recente da mesma versão de LTS.
  2. Crie uma ramificação de versão no nome de release-<version> com base na confirmação de referência.
  3. O backport muda por meio de PRs para a ramificação de lançamento.
    • A comunidade pode sugerir que determinadas confirmações sejam compatíveis com backport respondendo "@bazel-io flag" sobre problemas relevantes do GitHub ou PRs para marcá-las como possíveis bloqueadores de versões. A equipe do Bazel faz a triagem delas e decide se vai fazer o backport das confirmações.
    • Somente confirmações compatíveis com versões anteriores na ramificação principal podem ser transferidas por backport. Outras pequenas alterações para resolver conflitos de mesclagem são aceitáveis.
  4. Mudanças de backport usando o problema de solicitação Cherry-Pick para mantenedores do Bazel.

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

      1. Abra o pedido de escolha.
      2. Preencha os detalhes da solicitação.
        • Título: forneça um título conciso e descritivo para a solicitação.
        • IDs de confirmação: insira os IDs das confirmações que você quer selecionar. Se houver vários commits, separe-os com vírgulas.
        • Categoria: especifique a categoria da solicitação.
        • Revisores: para vários revisores, separe os IDs do GitHub com vírgulas.
      3. Definir o marco
        • Encontre a seção "Marco" e clique na configuração.
        • Selecione os bloqueadores de versão X.Y.Z adequados. Essa ação aciona o bot de seleção para processar sua solicitação para a ramificação "release-X.Y.Z".
      4. Envie o problema
        • Depois que todos os detalhes forem preenchidos e o miestone for definido, envie o problema.
    • O bot de escolha vai processar a solicitação e notificar se as confirmações estiverem qualificadas para a seleção. Se as confirmações forem selecionáveis, o que significa que não há conflito de mesclagem ao selecionar a confirmaçã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 com a ramificação de lançamento. Consulte este exemplo para conferir um exemplo de uma solicitação de escolha concluída.

  5. Identifique bloqueadores de versão e corrija os problemas encontrados na ramificação de lançamento.

    • A ramificação de versão é testada com o mesmo conjunto de testes em pós-envio e pipeline de teste downstream na CI do Bazel. A equipe do Bazel monitora os resultados dos testes da ramificação de lançamento e corrige as regressões encontradas.
  6. Crie um novo candidato a lançamento na ramificação de lançamento quando todos os bloqueadores de versão conhecidos forem resolvidos.

    • O candidato a lançamento é anunciado no bazel-discuss. A equipe do Bazel monitora os relatórios de bugs da comunidade do candidato.
    • Se novos bloqueadores de versão forem identificados, volte para a última etapa e crie um novo candidato a lançamento depois de resolver todos os problemas.
    • Não é permitido adicionar novos recursos ao branch de versão após a criação do primeiro candidato a lançamento.
  7. Envie o candidato a 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 versões principais e secundárias, envie a versão 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 é enviado apenas em um dia em que o próximo é um dia útil.
    • A versão é anunciada no bazel-discuss (em inglês). A equipe do Bazel monitora e aborda os relatórios de bugs da comunidade sobre a nova versão.

Relatar regressões

Se um usuário encontrar uma regressão em uma nova versão do Bazel, candidato a lançamento ou até mesmo no 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 compilação for bem-sucedida com o Bazel 6.1.0, mas falhar com o segundo candidato a lançamento de 6.2.0, você poderá dividir usando

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

Você pode definir a variável de ambiente BAZELISK_SHUTDOWN ou BAZELISK_CLEAN para executar os comandos do Bazel correspondentes para redefinir o estado de build, se necessário para reproduzir o problema. Para mais detalhes, confira a documentação sobre o recurso bisect do Bazelisk.

Lembre-se de fazer upgrade do Bazelisk para a versão mais recente se quiser usar o recurso de bisect.

Compatibilidade de regras

Se você cria regras e quer manter a compatibilidade com diferentes versões do Bazel, consulte a página Compatibilidade de regras.