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 a longo prazo (LTS, na sigla em inglês). Esta página aborda as informações mais recentes sobre o modelo de lançamento do Bazel.
Matriz de suporte
| Versão LTS | Estágio de suporte | Versão mais recente | Fim do suporte |
|---|---|---|---|
| Bazel 10 | Contínuo | Conferir a página de lançamento contínuo | N/A |
| Bazel 9 | Ativo | 9.0.2 | Dez. 2028 |
| Bazel 8 | Manutenção | 8.6.0 | Dez. 2027 |
| Bazel 7 | Manutenção | 7.7.1 | Dez. 2026 |
| Bazel 6 | Descontinuado | 6.6.0 | Dezembro de 2025 |
| Bazel 5 | Descontinuado | 5.4.1 | Janeiro de 2025 |
| Bazel 4 | Descontinuado | 4.2.4 | Janeiro de 2024 |
Todas as versões LTS do Bazel podem ser encontradas 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.
- 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 (em inglês).
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, alinhada à mesma linha de base da versão interna 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:
- 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.
- Crie uma ramificação de lançamento no nome de
release-<version>do commit de linha de base. - 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.
- A comunidade pode sugerir determinados commits a serem transferidos respondendo "
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:
- Abra a solicitação de cherry-pick.
- 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.
- 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".
- 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 à ramificação de lançamento. Para um exemplo visual de uma solicitação de fazer cherry-pick concluída, consulte este exemplo .
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.
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 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 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?
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, e a equipe do Bazel monitora e aborda 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, versão candidata a lançamento ou até mesmo no HEAD do Bazel, 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 via
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.