Como 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 lançamentos 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
| Versão LTS | Estágio de suporte | Versão mais recente | Fim do suporte |
|---|---|---|---|
| Bazel 10 | Contínuo | Confira a página de lançamento contínuo | N/A |
| Bazel 9 | Ativo | 9.3.1 | Dez. 2028 |
| Bazel 8 | Manutenção | 8.8.2 | Dez. 2027 |
| Bazel 7 | Manutenção | 7.7.2 | Dez. 2026 |
| Bazel 6 | Descontinuado | 6.6.0 | Dezembro de 2025 |
| Bazel 5 | Descontinuado | 5.4.1 | Jan 2025 |
| Bazel 4 | Descontinuado | 4.2.4 | Janeiro de 2024 |
Todas as versões LTS do Bazel podem ser encontradas na página de versões no GitHub. O selo "Latest" no GitHub sempre indica a versão semântica mais recente, mesmo que um patch de manutenção para uma versão mais antiga tenha sido lançado mais recentemente.
Controle de versão de lançamento
O Bazel usa um esquema de controle de versão 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 é uma versão LTS.
- Uma versão secundária contém correções de bugs compatíveis com versões anteriores e recursos 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 pela adição de um hífen e um sufixo de data 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:
- Principal: 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 etapas de suporte:
- Contínuas: essa versão principal ainda está em pré-lançamento. A equipe do Bazel publica versões contínuas 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 para as versões secundárias.
- Manutenção: esta versão principal é uma versão LTS antiga no modo de manutenção. A equipe do Bazel só promete fazer o backport de correções de bugs críticos para problemas de segurança e de compatibilidade com o SO nesta versão LTS.
- Descontinuado: a equipe do Bazel não oferece mais suporte para essa versão principal. Todos os usuários precisam migrar para as versões mais recentes do Bazel LTS.
Cadência de lançamento
O Bazel publica regularmente versões para duas faixas de lançamento.
Versões contínuas
- As versões contínuas são coordenadas com a versão do Google Blaze e são lançadas do HEAD a cada duas semanas, aproximadamente. É uma prévia da próxima versão LTS do Bazel.
- As versões contínuas podem incluir mudanças incompatíveis. As flags incompatíveis são recomendadas para alterações interruptivas importantes. A implementação de alterações incompatíveis precisa seguir nossa política de compatibilidade com versões anteriores.
Versões LTS
- Versão principal: uma nova versão LTS deve 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 de 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 devem ser lançadas sob demanda para correções de bugs críticos.
- Uma versão LTS do Bazel entra no estágio de descontinuação depois de ficar no estágio de manutenção por 2 anos.
Para versões planejadas, confira nossos problemas de versão no GitHub.
Procedimento e políticas de lançamento
Para as versões contínuas, o processo é simples: a cada duas semanas, uma nova versão é criada, alinhada com o mesmo valor de referência da versão interna do Blaze do Google. Devido ao cronograma de lançamento rápido, não fazemos backport de nenhuma mudança em versões contínuas.
Para as versões LTS, o procedimento e as políticas abaixo são seguidos:
- Determine um commit de referência para a versão.
- Para uma nova versão principal do LTS, o commit de referência é 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 da mesma versão LTS.
- Crie uma ramificação de lançamento com o nome de
release-<version>a partir do commit de referência. - Faça o backport das mudanças por meio de PRs para a ramificação de lançamento.
- A comunidade pode sugerir que determinados commits sejam portados de volta 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 faz a triagem deles e decide se vai portar os commits de volta. - 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 que determinados commits sejam portados de volta respondendo
"
Faça o backport de mudanças usando o problema de solicitação de cherry-pick para os mantenedores do Bazel.
Os mantenedores do Bazel podem solicitar a seleção de commits específicos para 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:
- 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 selecionar. 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.
- 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 cherry-pick para processar sua solicitação para a ramificação "release-X.Y.Z".
- 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 estiverem qualificados para cherry-pick. Se os commits forem selecionáveis, ou seja, não houver conflito de mesclagem ao selecionar o commit, o bot vai criar uma nova solicitação de pull. Quando a solicitação de pull é aprovada por um membro da equipe do Bazel, os commits são selecionados e mesclados à ramificação de lançamento. Para um exemplo visual de uma solicitação de cherry-pick concluída, consulte este exemplo .
Identificar bloqueadores de lançamento e corrigir 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 na CI do Bazel. 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 o candidato.
- Se novos bloqueadores de lançamento forem identificados, volte para a ú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 após a criação da primeira versão candidata a lançamento. As cherry-picks são limitadas apenas a correções críticas. Se for necessário fazer cherry-pick, o requerente 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?
Enviar 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 o lançamento da ú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 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, em uma versão candidata a lançamento ou até mesmo no Bazel no HEAD, registre um bug no GitHub. Use o Bazelisk para bissectar o commit culpado e inclua 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, faça a bisseçã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 bazel correspondentes e redefinir o estado do build, se necessário, para
reproduzir o problema. Para mais detalhes, confira 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 bisect.
Compatibilidade de regras
Se você é autor de regras e quer manter a compatibilidade com diferentes versões do Bazel, consulte a página Compatibilidade de regras.