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
Versão LTS | Estágio de suporte | Versão mais recente | Fim do suporte |
---|---|---|---|
Bazel 9 | Contínuo | Conferir a página de lançamento gradual | N/A |
Bazel 8 | Ativo | 8.4.1 | Dezembro de 2027 |
Bazel 7 | Manutenção | 7.6.1 | Dezembro de 2026 |
Bazel 6 | Manutenção | 6.5.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 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:
- 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.
- Crie uma ramificação de lançamento com o nome
release-<version>
do commit de base. - 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.
- A comunidade pode sugerir que determinados commits sejam portados para versões anteriores respondendo "
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:
- 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 com vírgulas.
- 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".
- 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.
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.
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?
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.