O Google anunciou uma mudança na cadência de atualizações do Chrome: a partir do lançamento do Chrome 153, previsto para 8 de setembro, o navegador passará de uma versão estável a cada quatro semanas para publicar duas versões estáveis por mês. Na prática isso significa que mudanças, correções e pequenas melhorias chegarão com maior frequência, embora com um alcance menor em cada entrega para tentar manter a estabilidade.
De acordo com as informações publicadas pela equipe de Chromium, esta modificação afeta tanto os canais Beta como os estáveis em desktops e dispositivos móveis (Android e iOS). Os canais orientados para o desenvolvimento precoce — Dev e Canary — continuarão a manter o seu ritmo atual de publicações, e o ramo Extended Stable, pensada para clientes empresariais que precisam de janelas de atualização mais longas, permanecerá no seu ciclo de oito semanas. Você pode revisar a documentação oficial e o histórico de publicações no blog de Chromium e no site do Chrome Releases: blog.chromium.org e chromereleases.googleblog.com.

Por que dar este passo agora? Desde o Google, eles apontam que pacotes de mudanças menores facilitam a localização de erros e reduzem a disrupção para usuários e administradores. Actualizar com maior frequência mas com menos novidades por entrega facilita o diagnóstico posterior à colocação em produção, explicam, e confiam em que melhorias recentes em seus processos de desenvolvimento manterão a confiabilidade do navegador. Esta estratégia não é nova no mundo do software: muitas organizações preferem lançamentos incrementais e contínuos para minimizar o risco associado a grandes saltos funcionais.
Para os usuários finais, a mudança será, em geral, pouco traumático: as atualizações do Chrome continuam se pedindo em segundo plano, mas é provável que apareçam avisos de reinício com mais periodicidade. Se você é dos que raramente fecha o navegador, você notará mais reicnios necessários para aplicar as novas versões. Para as empresas e equipamentos de TI, a boa notícia é que a opção Extended Stable Ainda disponível para aqueles que precisam de prazos mais longos para testes e certificações; o guia de gerenciamento e políticas de implantação do Chrome Enterprise é um recurso útil para planejar esse tipo de mudanças: support.google.com/chrome/a/answer/7679408.

Em matéria de segurança, o Google mantém a política comum de adesivos: embora as correcções de segurança sejam agrupadas nos marcos de lançamento, o modelo atual estabelece atualizações semanais para reduzir a chamada “janela de adesivo” (patch gap) e assim limitar o tempo que os atacantes têm para aproveitar vulnerabilidades publicadas. Esta atenção constante aos adesivos é crítica se você tiver em conta o histórico recente de vulnerabilidades exploradas no Chrome; por isso é importante manter as atualizações automáticas ativadas e aplicar os reinícios quando solicitado. O histórico de avisos e adesivos pode ser consultado no blog oficial do Chrome Releases: chromereleases.googleblog.com.
Para desenvolvedores de extensões, integrações e responsáveis de qualidade, o novo ritmo implica ajustar testes e processos de lançamento. Com entregas mais frequentes há menos tempo para validar e mais necessidade de automação nos testes Consequentemente, os equipamentos devem adaptar a sua integração contínua e supervisão para detectar regressões rapidamente. Ao mesmo tempo, a possibilidade de reverter ou emitir correções menores com maior agilidade pode ser um alívio quando aparece uma falha em produção.
Em suma, a transição para um ciclo de duas semanas pretende combinar a velocidade de entrega com a redução do impacto por cada atualização. O Google aposta numa estratégia de mudanças incrementais e adesivos contínuos que, se acompanhar de boas práticas de gestão de versões e testes automatizados, pode melhorar a experiência de usuários e administradores. Se você quiser seguir a evolução dessas mudanças e ler os comunicados oficiais, as fontes primárias são o blog de Chromium e o canal do Chrome Releases; para contexto histórico sobre como foi variando a cadência do Chrome em anos anteriores, meios tecnológicos como The Verge cobriram o anterior ajuste de 2021 quando o ciclo se acelerou a quatro semanas: The Verge — mudança para ciclo de quatro semanas.
Relacionadas
Mas notícias do mesmo assunto.

RAMPART e Clarity redefinem a segurança dos agentes da IA com testes reprodutíveis e governança desde o início
A Microsoft apresentou duas ferramentas de código aberto, RAMPART e Clarity, que visam alterar a forma como a segurança dos agentes da IA é testada: uma máquina de computador e ...

Um único token de workflow do GitHub abriu a porta para a cadeia de fornecimento de software
Um único token de workflow do GitHub falhou na rotação e abriu a porta. Essa é a conclusão central do incidente em Grafana Labs após a recente onda de pacotes maliciosos publica...

Webworm 2025: o malware que se esconde em Discord e Microsoft Graph para evitar a detecção
As últimas observações de pesquisadores em cibersegurança apontam uma mudança de táticas preocupantes de um ator ligado à China conhecido como Webworm: Em 2025, ele introduziu p...

A identidade já não basta: a verificação contínua do dispositivo para uma segurança em tempo real
A identidade continua sendo a coluna vertebral de muitas arquiteturas de segurança, mas hoje essa coluna está se agride sob novas pressões: phishing avançado, kits que proxyam a...

A matéria escura da identidade está mudando as regras da segurança corporativa
O relatório Identity Gap: Snapshot 2026 publicado por Orchid Security coloca números a uma tendência perigosa: a "matéria escura" de identidade —contas e credenciais que não se ...

PinTheft o exploit público que pode ser root no Arch Linux
Um novo exploit público levou à superfície novamente a fragilidade do modelo de privilégios no Linux: a equipe de V12 Security baniu a falha como PinTheft e publicou um teste de...

YellowKey A falha do BitLocker que poderia permitir a um atacante desbloquear sua unidade com apenas acesso físico
A Microsoft publicou uma mitigação para uma vulnerabilidade de omissão de segurança de BitLocker conhecida como YellowKey (CVE-2026-45585), depois de seu teste de conceito ser d...