Modelo de lançamento

Conforme anunciado em 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 a 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 do GitHub.

Controle de versão de lançamento

O Bazel usa um esquema de controle de versão major.minor.patch Semântico Versioning.

• 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 transferidos 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 anexando um hífen e um sufixo de data ao número da próxima versão principal.

Por exemplo, um novo lançamento de cada tipo resultaria nestes números de versão:

• Principal: 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:

• Contínuo: 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 transfere recursos importantes e correções de bugs para as versões secundárias.
• Manutenção: essa versão principal é uma versão LTS antiga no modo de manutenção. A equipe do Bazel só promete transferir correções de bugs críticos para problemas de segurança e de compatibilidade do SO para essa 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 LTS mais recentes do Bazel.

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 LTS do Bazel.
• Os lançamentos contínuos podem enviar mudanças incompatíveis. As flags incompatíveis são recomendadas para mudanças importantes, e a implementaçã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 é esperada para ser cortada 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 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 são 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, consulte 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, uma nova versão é criada, alinhada à mesma linha de base do lançamento interno do Google Blaze. Devido à programação de lançamento rápido, não transferimos 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 linha de base para a versão.
   • Para uma nova versão LTS principal, o commit de linha de base é o HEAD da ramificação principal.
   • Para uma versão secundária ou de patch, o commit de linha de base é o HEAD da versão mais recente da mesma versão LTS.
2. Crie uma ramificação de lançamento no nome de release-<version> do commit de linha de base.
3. Transfira as mudanças por PRs para a ramificação de lançamento.
   • A comunidade pode sugerir determinados commits a serem transferidos respondendo "@bazel-io flag" em problemas ou PRs relevantes do GitHub para marcá-los como possíveis bloqueadores de lançamento. A equipe do Bazel os tria e decide se vai transferir os commits.
   • Somente commits compatíveis com versões anteriores na ramificação principal podem ser transferidos. Pequenas mudanças adicionais para resolver conflitos de mesclagem são aceitáveis.

4. Transfira as mudanças usando o problema de solicitação de Cherry-Pick para os mantenedores do Bazel.

   • Os mantenedores do Bazel podem solicitar fazer cherry-pick de commit(s) específicos para uma ramificação de lançamento. Esse processo é iniciado pela 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 deles com vírgulas.
     3. 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 fazer cherry-pick 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 marco for definido, envie o problema.

   • O bot de cherry-pick vai processar a solicitação e notificar se os commits são qualificados para cherry-picking. Se os commits forem cherry-pickable, o que significa que não há conflito de mesclagem ao escolher o commit, o bot vai criar uma nova solicitação de pull. Quando a solicitação de envio é aprovada por um membro da equipe do Bazel, os commits são escolhidos e mesclados na ramificação de lançamento. Para um exemplo visual de uma solicitação de fazer cherry-pick concluída, 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 conjunto de testes em postsubmit e pipeline de testes 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 uma nova versão candidata a lançamento na ramificação de lançamento quando todos os bloqueadores de lançamento conhecidos forem resolvidos.

   • A versão candidata a lançamento é anunciada no bazel-discuss, a equipe do Bazel monitora os relatórios de bugs da comunidade para a versão candidata.
   • Se novos bloqueadores de lançamento forem identificados, volte à última etapa e crie uma nova versão candidata a lançamento depois de resolver todos os problemas.
   • Não é permitido adicionar novos recursos à ramificação de lançamento depois que a primeira versão candidata a lançamento for criada. As escolhas são limitadas apenas a correções críticas. Se uma escolha for necessária, 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?

7. Envie a versão candidata 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 a última versão candidata a lançamento.
   • Para versões principais e secundárias, envie a versão dois dias úteis após a última versão candidata a lançamento, mas não antes de uma semana após a primeira versão candidata a lançamento.
   • A versão só é enviada em um dia em que o dia seguinte é um dia útil.
   • A versão é anunciada no bazel-discuss, a equipe do Bazel monitora e resolve 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, candidata a lançamento ou até mesmo no Bazel no HEAD, registre um bug no GitHub. Você pode usar o Bazelisk para bissectar o commit 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 a segunda versão candidata 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 de bissecção do Bazelisk .

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

Compatibilidade de regras

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