Google has announced a change in the pattern of Chrome updates: starting with the release of Chrome 153, scheduled for September 8, the browser will move from a stable version every four weeks to publishing two stable versions per month. In practice this means that changes, corrections and small improvements will come more often but with a smaller range in each delivery to try to maintain stability.
According to information published by the Chromium team, this modification affects both Beta and stable channels on desks and mobile devices (Android and iOS). Early development-oriented channels - Dev and Canary - will continue to preserve their current pace of publications, and the branch Extended Stable, designed for business customers who need longer update windows, will remain in their eight-week cycle. You can review the official documentation and publication history on the Chromium blog and on the Chrome Releases site: blog.chromium.org and chromerease.googleblog.com.

Why take this step now? From Google they point out that smaller exchange packages facilitate the location of errors and reduce disruption for users and administrators. Updating more often but with less news per delivery facilitates post-production diagnosis, explain, and trust that recent improvements in your development processes will maintain the reliability of the browser. This strategy is not new in the software world: many organizations prefer incremental and continuous launches to minimize the risk associated with large functional jumps.
For end users, the change will generally be untraumatic: Chrome updates continue to be installed in the background, but it is likely that reboot notices will appear more regularly. If you are one of the ones who rarely closes the browser, you will notice more reicnios needed to apply the new versions. For IT companies and equipment the good news is that the option Extended Stable remains available for those who need longer time frames for testing and certification; the Chrome Enterprise management guide and deployment policies is a useful resource for planning such changes: support.google.com / chrome / a / ansher / 7679408.

In the area of security, Google maintains the frequent patch policy: although security corrections are grouped in the launch milestones, the current model sets weekly updates to reduce the so-called "patch gap" and thus limit the time the attackers have to take advantage of published vulnerabilities. This constant attention to patches is critical if you take into account the recent history of vulnerabilities exploited in Chrome; therefore it is important to keep the automatic updates on and apply the reinitials when requested. The history of ads and patches can be consulted on the official Chrome Releases blog: chromerease.googleblog.com.
For extension developers, integrations and quality managers, the new pace involves adjusting tests and launch processes. With more frequent deliveries there is less time to validate and more need for automation in the tests and therefore the equipment must adapt its continuous integration and monitoring to detect regressions quickly. At the same time, the possibility of reversing or issuing minor corrections with greater agility can be a relief when a production failure appears.
In short, the transition to a two-week cycle is intended to combine delivery speed with impact reduction for each update. Google is committed to an incremental change strategy and continuous patches that, if accompanied by good automated version and test management practices, can improve the experience of users and administrators. If you want to follow the evolution of these changes and read the official releases, the primary sources are the Chromium blog and the Chrome Releases channel; for historical context on how Chrome's cadence has changed in previous years, technological media like The Verge covered the previous 2021 adjustment when the cycle accelerated to four weeks: The Verge - change to four-week cycle.
Related
More news on the same subject.

RAMPART and Clarity redefine the safety of IA agents with reproducible testing and governance from the start
Microsoft has presented two open source tools, RAMPART and Clarity, aimed at changing the way the safety of IA agents is tested: one that automates and standardizes technical te...

A single GitHub workflow token opened the door to the software supply chain
A single GitHub workflow token failed in the rotation and opened the door. This is the central conclusion of the incident in Grafana Labs following the recent wave of malicious ...

WebWorm 2025: the malware that is hidden in Discord and Microsoft Graphh to evade detection
The latest observations by cyber security researchers point to a change in worrying tactics of an actor linked to China known as WebWorm: in 2025 it has incorporated back doors ...

Identity is no longer enough: continuous verification of the device for real-time security
Identity remains the backbone of many security architectures, but today that column is cracking under new pressures: advanced phishing, real-time proxyan authentication kits and...

The dark matter of identity is changing the rules of corporate security
The Identity Gap: Snapshot 2026 report published by Orchid Security puts numbers to a dangerous trend: the "dark matter" of identity - accounts and credentials that are neither ...

PinTheft the public explosion that could give you root on Arch Linux
A new public explosion has brought to the surface again the fragility of the Linux privilege model: the V12 Security team named the failure as PinTheft and published a concept t...

YellowKey The BitLocker failure that could allow an attacker to unlock your unit with only physical access
Microsoft has published a mitigation for a BitLocker security omission vulnerability known as YellowKey (CVE-2026-45585) after his concept test was publicly leaked and the coord...