
Na semana de 14 de setembro de 2026, o próprio blog de lançamentos do Chrome anunciou tudo isto como sendo distribuído a usuários reais:
- 152.0.7977.130 para o Extended Stable, no Windows e no Mac
- 153.0.8010.47/.48 para o Stable no desktop, com 42 correções de segurança
- 154.0.8037.44/.45 para o Windows, descrito como “parte do nosso lançamento early stable para uma pequena porcentagem de usuários”
- 154.0.8037.49 para o Android, “para uma pequena porcentagem de usuários”
- 154.0.8037.41 para o Chrome no iOS, como o lançamento stable normal por lá
Três versões principais, em uma semana, todas atuais, nenhuma errada. Qualquer pessoa em qualquer uma delas responderia “qual navegador você está usando?” com “o Chrome mais recente”, e todas estariam falando a verdade.
É por isso que “Chrome, versão mais recente” no topo de um relatório de bug não é informação nenhuma. Vale a pena dedicar dez minutos a entender o que isso esconde, porque esse formato explica toda uma categoria de bugs que acontecem com algumas pessoas e não com outras.
Os canais, como o Google os define
Chrome não tem uma versão. Ele tem canais, cada um mantendo uma versão principal diferente a qualquer momento. Segundo a própria documentação do Google para administradores:
- O Stable “foi totalmente testado pela equipe de testes do Chrome e deve ser usado pela maioria dos seus usuários”. Ele é atualizado “a cada 2 ou 3 semanas para lançamentos menores, e a cada 4 semanas para lançamentos principais”.
- Os usuários do Extended Stable “recebem atualizações de recursos com menos frequência, mas continuam recebendo correções de segurança”, e ele é “atualizado a cada 8 semanas”. Na prática, ele fica uma versão principal atrás do Stable durante a maior parte do ciclo, que é a diferença entre 152 e 153 mostrada acima.
- O Beta é “uma prévia de 4 a 6 semanas do que está por vir na versão Stable do Chrome”.
- O Dev é “uma prévia de 9 a 12 semanas”, e o Canary é “uma versão futura do Chrome que ainda está em desenvolvimento”.
Beta, Dev e Canary são opcionais, e uma pessoa que escolheu um deles geralmente sabe disso. Stable e Extended Stable são os dois que importam para relatórios de bug, porque ninguém em nenhum dos dois escolheu nada: o Extended Stable é definido por um administrador, para a empresa inteira, muitas vezes anos atrás, e as pessoas que o usam não fazem ideia disso.
Lançamentos graduais, a parte que surpreende as pessoas
Um canal também não é uma versão, porque um lançamento não chega a todo mundo no canal de uma vez só. A documentação para desenvolvedores do Chrome é direta sobre isso:
O Chrome usa lançamentos graduais para cada canal, em vez de liberar uma versão nova para todos os usuários de uma vez e torcer para que dê certo. Isso significa que, no início, apenas um pequeno número de usuários de cada canal de lançamento recebe uma atualização. Isso pode começar com apenas 1% a 5% dos usuários, aumentando gradualmente até chegar a 100%.
Então, em uma quarta-feira qualquer, duas pessoas no Chrome Stable, no mesmo sistema operacional, no mesmo escritório, podem estar em versões principais diferentes, e nenhuma das duas fez nada para causar isso. “Early Stable” é essa primeira fatia com nome próprio: o lançamento 154 citado acima chegou aos usuários do Windows antes de o 153 terminar de se espalhar para todo o resto.
A consequência prática é um bug que aparece para uma pequena fração dos seus usuários e mais ninguém, começando em um dia em que você não fez deploy nenhum. Isso é indistinguível, olhando de dentro dos seus logs, de um bug causado por você, e o primeiro lugar onde a maioria das equipes procura é o próprio último lançamento.
- Fraco
- Dois usuários relatam que o seletor de datas está quebrado. Não fizemos deploy ontem. Deve ser um problema de dados.
- Melhor
- Dois relatórios, ambos no Chrome 154.0.8037.44 no Windows, que saiu como Early Stable ontem para uma pequena porcentagem de usuários. Todo o resto está no 153.0.8010.47 e sem problemas.
As versões mobile não são o mesmo navegador, de jeito nenhum
O Chrome no Android é Chrome de verdade: Blink, V8, o mesmo motor do desktop, com sua própria trilha de lançamento (153 em 15 de setembro, 154 para uma pequena porcentagem no dia 16).
O Chrome no iOS não é. As regras da App Store da Apple exigem que os navegadores usem o motor web do sistema, então o Chrome em um iPhone é o WebKit vestindo a interface do Chrome. Aquele lançamento citado acima, o 154 no iOS, é uma nova versão da interface em torno de um motor que muda quando o iOS muda, não quando o Chrome muda. Um bug de CSS relatado a partir do “Chrome no meu iPhone” é um bug do Safari, e reproduzi-lo no Chrome do seu desktop reproduz um navegador diferente. Já escrevemos sobre o que isso faz com os relatórios quando o Safari 27 foi lançado.
Como extrair a versão real de um relatório
Existem três formas, em ordem decrescente de chance de você conseguir uma resposta.
Peça chrome://version. Digitado na barra de endereço, ele mostra o build completo na
primeira linha, além do sistema operacional e da linha de comando. É um copia e cola só,
funciona no Android, e não deixa margem para ambiguidade. É a coisa certa a pedir para um
desenvolvedor ou um cliente técnico.
Leia o user agent. Algo do seu lado já está recebendo isso a cada requisição, então não há
nada que você precise pedir. A limitação que vale a pena conhecer é que o Chrome reduziu essa
string há alguns anos: os componentes minor, build e patch são enviados como zeros, então o que
você recebe é Chrome/153.0.0.0, e não o build que realmente foi lançado. O build completo está
disponível, mas só se você for buscá-lo ativamente: Sec-CH-UA-Full-Version-List é um client
hint de alta entropia, que um servidor só recebe depois de solicitá-lo com um cabeçalho
Accept-CH, ou que uma página pode ler através de navigator.userAgentData.getHighEntropyValues().
Nem a string reduzida nem o client hint dizem nada sobre o canal, porque Extended Stable 152 e
Stable 152 são a mesma versão por caminhos diferentes.
Pergunte para a pessoa. O que retorna “a mais recente”, por todos os motivos acima. A culpa não é dela: a versão está três cliques dentro de um menu e não significa nada para ela quando a encontra.
O padrão nas três formas é que as respostas confiáveis não vêm de perguntar. Elas vêm de algo na própria página lendo o navegador no momento em que a falha aconteceu, o que é o argumento a favor de fazer o relatório capturar seu próprio ambiente em vez de entrevistar quem o registrou. Nosso próprio guia de relatório de bug coloca o build do navegador no modelo por esse motivo, e a leitura honesta disso é que o modelo é um fallback para quando nada capturou isso automaticamente.
Session Replay
Extensão gratuita para Chrome. Um clique na página com problema captura a tela, o console e o log de rede, e entrega a você um link para colar no chamado.
O que isso significa para os testes
Duas conclusões práticas saem de tudo isso, e elas puxam em direções opostas ao conselho de sempre.
Testar “o Chrome mais recente” testa uma entre pelo menos três versões em produção. Se seus clientes incluem uma empresa de qualquer porte, alguns deles estão no Extended Stable, uma versão principal atrás, por oito semanas seguidas. Um recurso que depende de algo lançado na versão principal atual está quebrado para esses usuários de propósito, e sua matriz de testes continua verde. O artigo sobre testes cross-browser defende pensar em motores em vez de navegadores; o eixo da versão é o mesmo argumento um nível abaixo.
Um lançamento gradual é um suspeito, e é barato de checar. Quando relatórios começam sem nenhum deploy, antes de você revisar suas próprias mudanças, veja se os usuários afetados compartilham um número de build que mais ninguém tem. O blog de lançamentos do Chrome é público e datado, então a pergunta “algo foi lançado para uma fatia de usuários no dia em que isso começou?” leva um minuto para ser respondida.
O que levar disso
“Mais recente” é uma palavra sobre intenção, não sobre software. A versão que está de fato rodando é um fato, é algo que se pode descobrir, e é a diferença entre um relatório sobre o qual você pode agir e um relatório que manda você vasculhar o próprio histórico do git por uma tarde inteira.
O blog de lançamentos do Chrome é a fonte primária, e vale a pena ter em um leitor de feeds se dar suporte a navegador é o seu trabalho: Chrome Releases.