Modelo de lançamento

Conforme anunciado em a 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 lançamentos de suporte de longo prazo (LTS, na sigla em inglês). Esta página contém as informações mais recentes sobre o modelo de lançamento do Bazel.

Matriz de suporte

Todos os lançamentos do Bazel LTS podem ser encontrados na página de lançamento do GitHub (em inglês).

Controle de versão de lançamento

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

• Um lançamento principal contém recursos que não são compatíveis com a versão anterior. Cada versão principal do Bazel é um lançamento LTS.
• Um lançamento secundário contém correções de bugs compatíveis com versões anteriores e recursos transferidos da ramificação principal.
• Um lançamento 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 é o lançamento LTS ativo 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 é um lançamento LTS antigo 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 com o 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 mais recentes do Bazel LTS.

Cadência de lançamento

O Bazel publica lançamentos 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 do próximo lançamento do Bazel LTS.
• 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

Lançamentos LTS

• Lançamento principal: um novo lançamento LTS é esperado do HEAD aproximadamente a cada 12 meses. Quando um novo lançamento LTS é lançado, ele entra imediatamente no estágio ativo, e o lançamento LTS anterior entra no estágio de manutenção.
• Lançamento secundário: novas versões secundárias na faixa LTS ativa são esperadas para serem lançadas uma vez a cada dois meses.
• Lançamento de patch: novas versões de patch para lançamentos LTS nos estágios ativo e de manutenção são lançadas sob demanda para correções de bugs críticos.
• Um lançamento do Bazel LTS 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 (em inglês).

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 à mesma linha de base do lançamento interno do Google Blaze. Devido à programação de lançamento rápida, não transferimos nenhuma mudança para lançamentos contínuos.

Para lançamentos LTS, o procedimento e as políticas abaixo são seguidos:

1. Determine um commit de linha de base para o lançamento.
   • Para um novo lançamento LTS principal, o commit de linha de base é o HEAD da ramificação principal.
   • Para um lançamento secundário ou de patch, o commit de linha de base é o HEAD da versão mais recente do mesmo lançamento 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, e a equipe do Bazel monitora os relatórios de bugs da comunidade para a 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 for necessário fazer cherry-pick, 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 o lançamento oficial se nenhum outro bloqueador de lançamento for encontrado.

   • Para lançamentos de patch, envie o lançamento pelo menos dois dias úteis após a última versão candidata a lançamento.
   • Para lançamentos principais e secundários, envie o lançamento 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.
   • O lançamento só é enviado em um dia em que o dia seguinte é um dia útil.
   • O lançamento é anunciado no bazel-discuss (em inglês), e a equipe do Bazel monitora e resolve relatórios de bugs da comunidade para o novo lançamento.

Informar regressões

Se um usuário encontrar uma regressão em um novo lançamento do Bazel, uma versão candidata a lançamento ou até mesmo o 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 para 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.