Modelo de lançamento

Conforme anunciado na postagem original do blog, o Bazel 4.0 e versões mais recentes oferecem suporte a duas linhas de lançamento: lançamentos contínuos e lançamentos de suporte de longo prazo (LTS). Esta página contém 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çamento 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 versões anteriores. Cada versão principal do Bazel é um lançamento LTS.
• Uma versão secundária contém correções de bugs e recursos compatíveis com versões anteriores portados da ramificação 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 com um hífen e um sufixo de data anexados 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:

• Grave: 6.0.0
• Secundária: 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: esta versão principal ainda está em pré-lançamento, e a equipe do Bazel publica versões rolling do HEAD.
• Ativa: esta versão principal é a versão LTS ativa atual. A equipe do Bazel faz o backport de recursos importantes e correções de bugs nas versões secundárias.
• Manutenção: esta versão principal é uma versão LTS antiga em modo de manutenção. A equipe do Bazel promete fazer o backport de correções de bugs críticos para problemas de segurança e de compatibilidade com o SO nessa versão LTS.
• Descontinuado: a equipe do Bazel não oferece mais suporte a esta versão principal. Todos os usuários precisam migrar para versões LTS mais recentes do Bazel.

Cadência de lançamento

A Bazel publica regularmente lançamentos com duas faixas cada.

Lançamentos contínuos

• Os lançamentos contínuos são coordenados com o lançamento do Google Blaze e são disponibilizados do HEAD a cada duas semanas. É uma prévia da próxima versão do Bazel LTS.
• As versões progressivas podem enviar mudanças incompatíveis. As flags incompatíveis são recomendadas para grandes mudanças incompatíveis. A implantação de mudanças incompatíveis precisa seguir nossa política de compatibilidade com versões anteriores.

Versões LTS

• Versão principal: uma nova versão LTS será lançada do HEAD aproximadamente a cada 12 meses. Quando uma nova versão LTS é lançada, ela entra imediatamente na fase "Ativa", e a versão LTS anterior entra na fase "Manutenção".
• Versão secundária: Novas versões secundárias na trilha Active LTS devem ser lançadas a cada 2 meses.
• Versão de patch: novas versões de patch para versões LTS nas etapas ativa e de manutenção devem ser lançadas sob demanda para correções de bugs críticos.
• Uma versão LTS do Bazel entra na fase de descontinuação depois de ficar na fase de manutenção por dois anos.

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

Procedimento e políticas de lançamento

Para lançamentos contínuos, o processo é simples: aproximadamente a cada duas semanas, uma nova versão é criada, alinhando-se com a mesma base da versão interna do Google Blaze. 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, o procedimento e as políticas abaixo são seguidos:

1. Determine um commit de base para a versão.
   • Para uma nova versão LTS principal, o commit de base é o HEAD da ramificação principal.
   • Para uma versão secundária ou de patch, o commit de base é 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> do commit de base.
3. Faça backport das mudanças usando solicitações de pull para a ramificação de lançamento.
   • A comunidade pode sugerir determinados commits para serem portados para versões anteriores respondendo "@bazel-io flag" em problemas ou solicitações de pull relevantes do GitHub para marcá-los como possíveis bloqueadores de lançamento. A equipe do Bazel os tria e decide se fará a portabilidade para versões anteriores.
   • Somente commits compatíveis com versões anteriores na ramificação principal podem ser portados para versões anteriores. Pequenas mudanças adicionais para resolver conflitos de mesclagem são aceitáveis.

4. Faça o backport de mudanças usando o problema de solicitação de cherry-pick para mantenedores do Bazel.

   • Os mantenedores do Bazel podem solicitar a inclusão de commits específicos em uma ramificação de lançamento. Esse processo é iniciado com a criação de uma solicitação de cherry-pick no GitHub. É muito fácil:

     1. Abra a solicitação de cherry-pick
     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 dos commits que você quer fazer cherry-pick. Se houver vários commits, separe-os com vírgulas.
        • Categoria: especifique a categoria da solicitação.
        • Revisor(es): para vários revisores, separe os IDs do GitHub com vírgulas.
     3. Defina a etapa
        • Encontre a seção "Marco" e clique na configuração.
        • Selecione os bloqueadores de lançamento X.Y.Z adequados. Essa ação aciona o bot de cherry-pick para processar sua solicitação da ramificação "release-X.Y.Z".
     4. Enviar o problema
        • Depois de preencher todos os detalhes e definir o marco, envie o problema.

   • O bot de cherry-pick vai processar a solicitação e notificar se os commits forem qualificados para cherry-picking. Se os commits puderem ser escolhidos, ou seja, não houver conflito de mesclagem ao escolher 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, os commits são escolhidos e mesclados à ramificação de lançamento. Para ver um exemplo visual de uma solicitação de cherry-pick concluída, consulte este exemplo.

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

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

6. Crie um novo candidato a lançamento na ramificação de lançamento quando todos os bloqueadores de lançamento conhecidos forem resolvidos.

   • O candidato a lançamento é anunciado em 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 a lançamento depois de resolver todos os problemas.
   • Não é permitido adicionar novos recursos à ramificação de lançamento após a criação da primeira versão candidata; as seleções de alterações (cherry-picks) são limitadas apenas a correções críticas. Caso seja necessária uma alteração específica, o solicitante deve responder às seguintes perguntas: Por que essa alteração é crucial e quais benefícios ela proporciona? Qual a probabilidade dessa mudança introduzir uma regressão?

7. Envie a candidata a lançamento como a versão oficial se não forem encontrados mais bloqueadores de lançamento.

   • Para lançamentos de patch, envie a versão pelo menos dois dias úteis depois que a última versão candidata for lançada.
   • Para lançamentos principais e secundários, faça o push dois dias úteis após a última versão candidata, mas não antes de uma semana após a primeira versão candidata.
   • A versão só é enviada em um dia em que o dia seguinte é útil.
   • O lançamento é anunciado em bazel-discuss, a equipe do Bazel monitora e responde aos 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, um candidato a lançamento ou até mesmo o Bazel no HEAD, registre um bug no GitHub. Use o Bazelisk para dividir o commit causador do problema e inclua essas informações no relatório de bug.

Por exemplo, se o build for bem-sucedido com o Bazel 6.1.0, mas falhar com o segundo candidato a lançamento do 6.2.0, você poderá fazer a bissecção 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 bazel correspondentes e redefinir o estado da compilação, caso seja necessário para reproduzir o problema. Para mais detalhes, consulte a documentação sobre o recurso bisect do Bazelisk.

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

Compatibilidade de regras

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