Modelo de lançamento

Como anunciado na postagem original do blog, o Bazel 4.0 e as versões mais recentes oferecem suporte a duas faixas de lançamento: lançamentos graduais e de suporte de longo prazo (LTS). Esta página aborda as informações mais recentes sobre o modelo de lançamento do Bazel.

Matriz de suporte

Todas as versões LTS do Bazel podem ser encontradas na página de lançamentos 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 versões anteriores. 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 portados do ramo principal.
• Uma versão de patch contém correções de bugs críticos.

Além disso, as versões de pré-lançamento são indicadas anexando um hífen e um sufixo de data ao próximo número de versão principal.

Por exemplo, uma nova versão de cada tipo resultaria nestes números de versão:

• Principal: 6.0.0
• Menor: 6.1.0
• Patch: 6.1.2
• Pré-lançamento: 7.0.0-pre.20230502.1

Estágios de suporte

Para cada versão principal do Bazel, há quatro estágios de suporte:

• Rolling: essa versão principal ainda está em pré-lançamento. A equipe do Bazel publica lançamentos contínuos do HEAD.
• Ativo: essa versão principal é a versão LTS ativa atual. A equipe do Bazel faz backports de recursos importantes e correções de bugs nas versões secundárias.
• Manutenção: esta versão principal é uma versão LTS antiga no modo de manutenção. A equipe do Bazel só promete fazer a backport de correções de bugs críticas para problemas de segurança e de compatibilidade do SO nesta versão LTS.
• Descontinuado: a equipe do Bazel não oferece mais suporte a essa versão principal. Todos os usuários precisam migrar para versões mais recentes do Bazel LTS.

Cadência de lançamento

O Bazel publica versões regularmente 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 lançados do HEAD a cada duas semanas. É uma prévia da próxima versão do Bazel LTS.
• As versões graduais podem enviar mudanças incompatíveis. As flags incompatíveis são recomendadas para mudanças importantes, e o lançamento de mudanças incompatíveis deve seguir nossa política de compatibilidade com versões anteriores.

Versões LTS

• Lançamento principal: espera-se que um novo lançamento LTS seja cortado do HEAD aproximadamente a cada 12 meses. Quando uma nova versão LTS é lançada, ela entra imediatamente no estágio ativo, e a versão LTS anterior entra no estágio de manutenção.
• Versão secundária: novas versões secundárias na faixa de LTS ativa devem 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 de manutenção serão lançadas sob demanda para correções de bugs críticos.
• Uma versão LTS do Bazel entra no estágio de descontinuação depois de ficar no estágio de manutenção por dois anos.

Para lançamentos programados, consulte nossos problemas de lançamento no GitHub.

Políticas e procedimentos de lançamento

Para lançamentos contínuos, o processo é simples: a cada duas semanas, uma nova versão é criada, alinhada com a mesma base de referência do lançamento interno do Blaze do Google. Devido ao cronograma de lançamento rápido, não fazemos backport de nenhuma mudança para lançamentos contínuos.

Para versões LTS, siga o procedimento e as políticas abaixo:

1. Determine uma confirmação de base para a versão.
   • Para uma nova versão LTS principal, a confirmação de referência é a cabeçalho 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 atual da mesma versão LTS.
2. Crie uma ramificação de lançamento com o nome release-<version> a partir do commit de referência.
3. Faça a retrocompatibilidade de mudanças por meio de PRs na ramificação de lançamento.
   • A comunidade pode sugerir que algumas confirmações sejam enviadas de volta respondendo "@bazel-io flag" em problemas ou PRs relevantes do GitHub para marcá-las como possíveis bloqueadores de lançamento. A equipe do Bazel faz a triagem e decide se vai enviar as confirmações de volta.
   • Somente as confirmações compatíveis com versões anteriores na ramificação principal podem serportadas de volta. Outras mudanças menores para resolver conflitos de mesclagem são aceitáveis.

4. As mudanças de backport usando o problema de solicitação de escolha de cereja para os 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 pela criação de uma solicitação de seleção no GitHub. É muito fácil:

     1. Abra a solicitação de escolha de melhores partes.
     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 dos commits 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 deles com vírgulas.
     3. Definir 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 escolha para processar sua solicitação na ramificação "release-X.Y.Z".
     4. Enviar o problema
        • Depois que todos os detalhes forem preenchidos e o flag estiver definido, envie o problema.

   • O bot de seleção vai processar a solicitação e notificar se os commits estão qualificados para a seleção. Se os commits forem cherry-pickáveis, o que significa que não há conflito de mesclagem ao selecionar o commit, o bot vai criar uma nova solicitação de envio. Quando a solicitação de pull é aprovada por um membro da equipe do Bazel, as confirmações são selecionadas e mescladas na ramificação de versão. Para conferir um exemplo visual de uma solicitação de escolha, consulte este exemplo .

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

   • A ramificação de lançamento é testada com o mesmo pacote de testes no postsubmit e pipeline de teste downstream no CI do Bazel. A equipe do Bazel monitora os resultados dos testes da versão e corrige todas as regressões encontradas.

6. Crie um novo candidato à versão na ramificação de versão quando todos os bloqueadores de versão conhecidos forem resolvidos.

   • O candidato à versão é anunciado no bazel-discuss, e a equipe do Bazel monitora os relatórios de bugs da comunidade para o candidato.
   • Se novos bloqueadores de lançamento forem identificados, volte à última etapa e crie um novo candidato à versão depois de resolver todos os problemas.
   • Não é permitido adicionar novos recursos à ramificação de lançamento depois que a primeira versão candidata é criada. As escolhas são limitadas a correções críticas. Se for necessário escolher o que é melhor, o solicitante precisa responder às seguintes perguntas: por que essa mudança é essencial e quais benefícios ela oferece? Qual é a probabilidade de essa mudança introduzir uma regressão?

7. Enviar a versão candidata 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 a última versão candidata.
   • Para lançamentos principais e secundários, envie a versão dois dias úteis após o lançamento do último candidato, mas não antes de uma semana após o lançamento do primeiro candidato.
   • A versão só é enviada em um dia em que o dia útil seguinte é um dia útil.
   • O lançamento é anunciado no bazel-discuss, a equipe do Bazel monitora e aborda os relatórios de bugs da comunidade para a nova versão.

Informar regressões

Se um usuário encontrar uma regressão em uma nova versão do Bazel, candidato a versão ou até mesmo o Bazel no HEAD, registre um bug no GitHub. Você pode usar o Bazelisk para bisseccionar a confirmação do culpado e incluir essas informações no relatório de bugs.

Por exemplo, se o build for bem-sucedido com o Bazel 6.1.0, mas falhar com o segundo candidato à versão 6.2.0, você poderá fazer a bissetorização em

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 Bazel correspondentes e redefinir o estado do build, se necessário, para reproduzir o problema. Para mais detalhes, consulte a documentação sobre o recurso de bisset do Bazelisk.

Não se esqueça de atualizar o Bazelisk para a versão mais recente para usar o recurso de bissetor.

Compatibilidade de regras

Se você é um autor de regras e quer manter a compatibilidade com diferentes versões do Bazel, confira a página Compatibilidade de regras.