Modelo de lançamento

Conforme anunciado na postagem original do blog, o Bazel 4.0 e versões mais recentes oferecem suporte a duas faixas de lançamento: lançamentos contínuos 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ç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
• Leve: 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 apenas 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

O Bazel publica regularmente lançamentos para duas faixas de lançamento.

Lançamentos graduais

• 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.
• Os lançamentos graduais 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 faixa de LTS ativo devem ser lançadas a cada dois 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íticas.
• Uma versão LTS do Bazel entra na fase de descontinuação após 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: a cada duas semanas, aproximadamente, um novo lançamento é criado, alinhado com a mesma base 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, 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 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> do commit de base.
3. Faça o backport das mudanças usando PRs na ramificação de lançamento.
   • A comunidade pode sugerir que determinados commits sejam 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 faz a triagem e decide se vai portar os commits 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.
        • Revisores: 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 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 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 depois que o primeiro candidato a lançamento é criado. Os cherry-picks são limitados apenas a correções críticas. Se for necessário fazer um cherry-pick, 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. 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, faça o push 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, e a equipe do Bazel monitora e resolve 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, 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

É possível definir a variável de ambiente BAZELISK_SHUTDOWN ou BAZELISK_CLEAN para executar os comandos do 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 bisect do Bazelisk.

Não se esqueça de atualizar o Bazelisk para a versão mais recente e 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.