Chrome’s Two-Week Release Cycle: What Changed and How Agencies Should Adjust QA

The Chrome release cycle is now two weeks long. Chrome 153 reached the stable channel on September 8, 2026, and a new major version has followed every two weeks since. Chrome 157 is scheduled for stable on November 3, the day this post runs.

Our Chrome XSLT removal post showed one effect of the change. A removal tied to Chrome 158 arrives on November 17, sooner than the version number suggests. This post goes deeper on the Chrome release cycle itself: what Google changed, what stayed the same, how Edge and Firefox compare, and what agencies should change in their testing.

The short version: Beta now runs three weeks ahead of stable, and Early Stable reaches a small share of users about two weeks ahead. Extended Stable still moves every eight weeks for managed Windows and Mac fleets. Edge and Firefox also ship every two weeks. Put a test machine on Chrome Beta, read the release notes every two weeks, and convert every milestone number into a date.

What changed in the Chrome release cycle

Google announced the change on March 3, 2026, in its two-week release post. Chrome had shipped a new milestone every four weeks since 2021. From Chrome 153, each new Beta and Stable version ships every two weeks.

The change covers desktop, Android and iOS. Google says, "There will be no changes to the Dev and the Canary channels." Its reasoning is that "their smaller scope minimizes disruption and simplifies post-release debugging." Each release carries fewer changes, so a break should be easier to trace.

Three timing rules matter for testing:

• Beta ships three weeks before each stable release, Google says.
• Early Stable goes to a small percentage of users first. Google added it with Chrome 110 in 2023, one week ahead of full stable. In the Chromium Dash schedule, it now lands about two weeks ahead.
• Weekly security updates continue between major releases. Google added those in 2023.

So a site that breaks in Chrome 158 can break for some visitors on November 4, not November 17.

Upcoming Chrome releases, as of October 2026

These dates come from Chromium Dash, read October 21, 2026. Google can move them, so check the schedule before you plan around one.

The holidays stretch the gaps. Chrome 159 comes three weeks after 158, and Chrome 160 comes four weeks after 159. From January the two-week rhythm returns. For the CMS, PHP and other year-end dates, see our Q4 2026 platform calendar.

Extended Stable stays on eight weeks

Extended Stable is the slower Chrome release cycle for managed devices. Google’s Extended Stable help page says it is for "enterprises that cannot accommodate a 2-week release cycle."

Here is how it works now:

• A new Extended Stable milestone ships every eight weeks, which is every fourth stable release.
• For the first two weeks, Stable and Extended Stable are the same build.
• For the next six weeks, Extended Stable gets weekly security fixes backported from Stable.
• It runs on Windows and Mac only. Google says it “is not supported on mobile.”
• Admins choose it with the TargetChannel policy.

Google adds a warning. Some complex security changes "might only be available on the Stable channel." Extended Stable trades some security for fewer feature changes.

For Chromebooks, Google’s announcement says extended release options continue, with more detail on managed devices to come.

One more caution. As of October 21, 2026, Google’s general help page on release channels still describes four-week major releases. Check the date on any Google help page you forward to a client.

How deprecations and origin trials are timed now

Google’s deprecation and removal page describes the usual path. Blink engineers post an intent to deprecate. Chrome shows warnings in DevTools. Chrome then turns the feature off by default and offers temporary access through a deprecation trial, a flag or an enterprise policy. The code is removed later.

The page gives no fixed notice period. It says a deprecated feature "typically remains available for several versions of Chrome before being disabled by default." Under the old cycle, several versions meant several months. Under the new one, the same count covers half the time. Google has not said whether it will lengthen notice periods to make up for that.

Origin trials have the same issue. Google’s origin trials guide says trials are "limited in duration and usage." It gives no length in weeks. As of October 2026, we have not found Google guidance on how trial lengths change under two-week releases.

XSLT shows the math. Its deprecation trial and enterprise policy end with Chrome 176 on August 17, 2027. That is 18 versions after Chrome 158. Under the old four-week cycle, 18 versions would have taken about 16 months. Now they take nine months.

How Edge and Firefox compare

Microsoft Edge moved first. Microsoft’s June 11 announcement says Edge moved to a two-week cycle starting with Edge 152 on August 27, 2026. Edge Extended Stable now updates "every fourth release (for example, 156, 160, 164)," still eight weeks apart. Its supported path for piloting Beta is Edge Enterprise Preview.

Edge stable dates sit close to Chrome’s but do not match. The Edge release schedule lists Edge 158 for the week of November 19, 2026, and Edge 159 for the week of December 3, before Chrome 159. Microsoft calls its dates approximate. It says Extended Stable is only for managed environments. We have not seen Microsoft confirm that Edge 158 drops XSLT along with Chrome.

Firefox calls its move an experiment. Mozilla’s Sylvestre Ledru announced it on July 9, 2026, in a dev-platform post. The plan moves Firefox desktop and Android "from a 4-week release cadence to a 2-week release cadence," starting with Firefox 155 on September 1. The post says, "This will be an experiment," and Mozilla will adjust if needed. Firefox ESR keeps its own yearly schedule, as our Firefox ESR 140 end-of-life post explains.

So all three major desktop browser makers outside Apple now ship every two weeks. Our browser engines guide covers which browsers share Chrome’s engine and inherit its changes.

What agencies should change in QA for the Chrome release cycle

Test on Beta every two weeks. Beta gives you three weeks of warning. Keep one test machine or browser profile on Chrome Beta and one on Dev. Run your key client pages through Beta each time a new Beta lands. On the current schedule, that is a Wednesday every two weeks.

Pin browsers in automated tests. Chrome for Testing is a Chrome build that does not auto-update. Google built it because "None of this is possible with an auto-updating browser binary." Pin your test runs to the current Stable version. Add a second job against Beta so it fails first.

Read the release notes on a schedule. Chrome posts release notes for each version, and Google posts feature notes for each Beta. Put a recurring reminder on the Beta date. Assign one person to read them and flag anything that touches client sites.

Watch chromestatus.com for removals. Each feature has a Chrome Platform Status entry with its timeline. Google’s deprecation page says, "Timelines are also published within the chromestatus.com entry for a deprecated feature."

Rewrite version-count support terms. "Latest two versions" now covers about a month. Define support by date, or name the current Stable and Extended Stable channels.

Kiosks, library computers and managed fleets

The Chrome release cycle hits hardest on public computers in libraries, lobby kiosks and shared lab machines. They often need a stable setup. Chrome gives admins three tools. Google’s Windows update guide describes them.

• Extended Stable through the TargetChannel policy. This is the safest way to slow change down.
• Target version prefix override pins Chrome to a major version, such as 158.. Google says pinning “should be done only temporarily.”
• Rollback to target version moves Chrome back to a pinned version. It works only for the three most recent major releases. Under two-week releases, that is about six weeks of history.

Google warns, "We do not recommend turning off browser updates." It also says, "Don’t forget to unpin users’ computers or they can fall behind on critical security updates." If a kiosk runs a web app you built, test that app against Beta. Do not rely on the kiosk staying on an old version.

How to track a removal like XSLT

The XSLT removal is a good template for any removal under the new Chrome release cycle. Our earlier Manifest V2 removal post followed a similar staged path.

1. Find the timeline. Start from Google’s deprecation page for the feature and its chromestatus entry.
2. Convert milestones to dates. Look up each version in Chromium Dash. Note the Beta and Early Stable dates, not only Stable.
3. Test on Beta. Chrome 158 Beta opened October 28, three weeks before stable.
4. Watch the warnings. Deprecated features show up in the DevTools Issues panel and the console.
5. Collect reports from real visits. A ReportingObserver watching deprecation reports can catch the ID XSLT. Managed fleets can use Google’s Legacy Technology Report. It lists sites that use deprecated features, for up to 100 allowlisted URLs. It needs at least five enrolled browsers per organizational unit, active for 28 days.

Frequently Asked Questions