Chromium engineering
Chrome's two-week release cycle: what fork owners need to know
By Usman Khan, Lead Chromium Developer
Technically reviewed by Hamza Ali, Senior Chromium Developer
Published 10 min read
Release-cadence changes do not happen often, and this one is a real change, not a minor adjustment: Chrome is now shipping major versions twice as often as it did before September 2026. If you build on Chromium in any form, it is worth fifteen minutes to understand exactly what moved, what did not, and what to actually do about it.
What actually changed, and when
Chrome 153, released 8 September 2026, was the first version under the new two-week major release cycle. Before that date, Chrome shipped a new major version roughly every four weeks. The change affects how often new major-version numbers appear in Chrome’s stable channel; it does not change how security patches work. Chrome has always shipped security fixes between major releases when needed, and it continues to do so now.
The Extended Stable channel, which exists specifically so enterprises are not forced onto every release, still moves to a new milestone every eight weeks. Chromium has no formal long-term-support branch beyond that — Extended Stable is the slowest officially supported option.
A short history of Chrome’s release cadence
Chrome’s cadence has sped up more than once. Each change followed the same logic: ship improvements and fixes to users faster, at the cost of more frequent version bumps for anyone downstream.
- 2008–2010: Chrome shipped without a fixed, published cycle in its first two years.
- 2010: Chrome adopted a six-week cycle across four channels — Canary, Dev, Beta and Stable — which held, roughly, for the next decade.
- 2021 (Chrome 94): Chrome moved to a four-week cycle and introduced Extended Stable as a slower, opt-in channel for organizations that did not want every release.
- 2026 (Chrome 153): Chrome moved to the current two-week cycle. Extended Stable’s eight-week cadence was not changed.
Release channels, briefly explained
“Chrome” is not one release train — it is five, each aimed at a different audience, and the two-week change only affects one of them directly.
- Canary. Built nightly, unstable by design, used by Chromium engineers and extension developers who need to see tomorrow’s changes today.
- Dev. Updates roughly weekly with features that are further along but not yet frozen for release.
- Beta. Runs one full cycle ahead of Stable. This is where most compatibility testing against an upcoming release actually happens.
- Stable. The default channel almost everyone runs, and the one now moving every two weeks instead of four.
- Extended Stable. A slower, opt-in channel alongside Stable, aimed at managed and enterprise fleets. Unaffected by this change — still every eight weeks.
It is not only fork maintainers who feel this
Most coverage of this change talks about Chromium forks specifically, but a faster release cycle touches a few other parts of a browser-dependent product:
- Extension developers see Chrome’s current platform behavior change more often — permission prompts, API availability and deprecation timelines move on the same two-week clock, so an extension that assumes “the current Chrome” now needs testing against a faster-moving target.
- QA and regression teams that test against each Chrome release now have half as much calendar time per cycle if they try to match every version, which usually means automating more of the regression pass or picking a slower cadence deliberately rather than by default.
- Enterprise IT and security teams are mostly insulated by Extended Stable, but any internal tooling, compatibility testing, or policy documentation that assumed a four-week cycle for regular Chrome now needs a one-line update, even if the team itself stays on Extended Stable.
- Embedded-browser teams (CEF, WebView2) inherit this indirectly: the underlying Chromium releases those frameworks package are moving on the same faster schedule, which shortens the window between “a new Chromium version exists” and “our embedding framework offers it.”
How other browser engines compare
Chrome is not the only browser with a published release cadence, and the differences matter if your product spans more than one engine.
| Browser | Regular cadence | Slower-track option |
|---|---|---|
| Chrome / Chromium | Every 2 weeks (Stable, since Chrome 153) | Extended Stable, every 8 weeks |
| Firefox | Every 4 weeks | Extended Support Release (ESR), roughly once a year |
| Safari | Tied to macOS and iOS releases, about once a year, with point updates in between | No separate long-term channel |
| Microsoft Edge | Follows Chromium’s 2-week Stable cadence | Edge has its own Extended Stable option, set independently of Chrome’s |
A product that ships Chromium and Firefox builds side by side is now reconciling two different clocks: a two-week Chromium cycle and a four-week Firefox one. See our Firefox browser modification service for how we handle Gecko’s side of that.
Where the release cadence sits in your stack
Your product
The browser, extension or embedded app your users see.
Your patch series and build pipeline
The changes you maintain, and how you rebase, build and sign a release.
Chromium release channel
Stable (every 2 weeks) or Extended Stable (every 8 weeks) — this is the layer that just sped up.
Operating system and distribution
Windows, macOS or Linux, and the update channel that gets a build to users.
- Your product
- Our engineering
- Upstream: third-party code we build on
- Platforms and release
The one decision this actually forces
For a team maintaining its own Chromium fork, the two-week change does not add new work by itself — rebase effort is driven mostly by how much upstream changed and how invasive your own patches are, not by how the release calendar is labeled. What it does is force a decision that was easier to defer under the old, slower cadence: follow every release, or standardize on Extended Stable.
How invasive is your patch series?
A small set of narrow, well-isolated patches tends to survive frequent rebases cheaply. A large or deeply hooked patch series compounds conflict risk every time you rebase, so fewer, larger rebases are often cheaper overall.
How much do you need the newest web-platform features?
Product teams chasing new web APIs or performance work benefit from every-two-week releases. Teams shipping a stable, policy-driven browser usually do not need the newest release the day it ships.
Can your QA cycle compress to two weeks?
If regression testing is manual or only partially automated, a two-week rebase cadence is hard to sustain. Extended Stable’s eight-week window gives QA room to run a full pass without racing the next release.
Pick one cadence and write it down
Either choice is workable on its own. What is not workable is an undocumented, inconsistent cadence that drifts further from upstream every time a rebase gets deprioritized.
Whichever you choose, the actual mechanics of a rebase — reapplying a patch series, resolving internal API breaks, rebuilding and testing on every platform — do not change. We cover that process step by step in our version porting playbook.
What to do in the next two weeks
Audit your current cadence
Find out, in writing, how many Chrome versions behind your fork is right now and when the last rebase actually happened. Most teams discover this is informal knowledge, not a number.
You get: A clear gap number, not a guess.
Pick a cadence on purpose
Run the four questions above instead of defaulting to whatever cadence you happened to use last year. Every-release and Extended Stable are both defensible; an undecided default is not.
You get: One documented cadence decision.
Update your QA and release calendar
Block the engineering time a two-week or eight-week cadence actually needs, before the next in-the-wild security fix forces an unplanned rebase on top of it.
You get: A release calendar that matches reality.
Write the decision down
One dated paragraph in the repo — which cadence, why, and who owns watching upstream — so the next engineer does not have to re-litigate it in the middle of an incident.
You get: A decision nobody has to re-make under pressure.
What this does not change
Three things stayed the same on 8 September 2026: Chrome’s Extended Stable channel still moves every eight weeks; the web platform APIs your browser or extension relies on are still covered by Chromium’s usual stability guarantees, independent of how often the major version number changes; and there is still no formal long-term-support branch beyond Extended Stable. The cadence of new major versions changed. The support model around them did not.
Final takeaway
A faster release cycle is a scheduling change, not a workload multiplier — but it does remove the option of not deciding. If your fork has been rebasing “whenever there’s time,” Chrome 153 is a reasonable point to pick a cadence on purpose: every release for a small, fast-moving patch series, or Extended Stable for a larger one, documented so the decision does not have to be re-made under pressure during the next urgent security fix.
Frequently asked questions
How often does Chrome release a new major version now?
Chrome now ships a new major version every two weeks, starting with Chrome 153 on 8 September 2026 — down from the previous four-week cycle. Security fixes continue to ship between major releases, and the Extended Stable channel still updates every eight weeks for teams that opt into it.
What are Chrome’s release channels?
Canary is an unstable nightly build for Chromium developers. Dev updates roughly weekly with early, sometimes-unfinished features. Beta is one full cycle ahead of Stable and is where most compatibility testing happens. Stable is the default channel most users and Chrome’s regular releases ship on, now every two weeks. Extended Stable sits alongside Stable as a slower, opt-in channel for managed and enterprise deployments, moving every eight weeks.
How is Firefox’s release cycle different from Chrome’s?
Firefox ships a new major version on its regular channel about every four weeks, which Chrome itself used to match before the September 2026 change. Firefox also offers an Extended Support Release (ESR), a separate, longer-lived build that moves roughly once a year and is the closest equivalent to Chrome’s Extended Stable, though on a slower cycle.
Does the two-week cycle apply to Firefox or Brave as well?
No. Firefox ships on its own roughly four-week cadence, and Brave rebases onto Chromium on its own schedule rather than matching Chrome release for release. The two-week change is specific to Chrome and the upstream Chromium project it is built from.
Should our fork rebase on every Chrome release, or follow Extended Stable?
It depends mainly on how large and invasive your patch series is. A small, well-isolated set of patches can often keep up with every two-week release and ship new features and fixes sooner. A larger or more invasive patch series is usually safer on the eight-week Extended Stable cadence, which gives more time per rebase at the cost of being further behind on new upstream capabilities.
What happens if we keep rebasing every eight weeks like before?
Nothing breaks immediately, but the gap you are reconciling at each rebase is now larger than it used to be: four regular Chrome releases land in that same eight-week window instead of two. Security exposure and merge-conflict size both grow accordingly, even though your own rebase cadence has not changed.
Does this change how much fork maintenance costs?
Not automatically. A faster upstream cadence does not double engineering time, since most of each release is incremental change. What it changes is the decision in front of you: rebase more often for a smaller diff each time, or stay on Extended Stable and accept a larger diff every eight weeks. Either is workable; drifting without choosing either is what gets expensive.
Not sure which cadence fits your fork?
We maintain Chromium and Firefox forks on both cadences and can assess an existing fork — patch-series size, rebase history and security gap — before you commit to one. See our version porting and upstream maintenance service.