Keeping a Chromium fork up to date: the version porting playbook

Forking Chromium gets a lot of planning attention up front: architecture, features, platforms. What decides whether the fork is still viable a year later is less visible: what happens every time upstream ships a new release.

Why this is a recurring job, not a one-time port

Chrome moved to a two-week major release cycle with Chrome 153 on 8 September 2026. Before that, a new major version shipped every four weeks. Security fixes ship between major releases. Chrome’s Extended Stable channel, meant for enterprises, moves to a new milestone every eight weeks, and Google keeps backporting security fixes to it until the next one. There is no long-term support branch beyond that. A fork in production has to track this cadence in some form for as long as it has users.

Whichever you follow, there are two ways to bring changes in:

A common pattern is a mix: full rebases on a regular cycle, with security backports in between when an urgent fix cannot wait for the next rebase.

The rebase cycle

1. 1

   Upstream ships

   A new Chromium release is tagged, usually carrying security fixes, some of them worth backporting immediately.

2. 2

   Reapply the patch series

   Each patch is reapplied in order against the new tag, and conflicts are resolved patch by patch rather than as one large merge.

3. 3

   Fix internal API breaks

   Renamed classes, moved files and refactored internals are updated at each call site the patch series touches.

4. 4

   Rebuild and regression test

   A full build on every supported platform, then a regression pass against the fork’s own features, not just upstream’s test suite.

5. 5

   Ship the rebased release

   A signed build goes out through the fork’s own update channel, and the cycle starts again on the next release you follow.

Tools and techniques

• Keep your code apart from upstream. Put new code in your own directories and hook into upstream at a few call sites. Brave does this with its chromium_src overrides, which replace upstream code at build time without editing the upstream files.
• Keep changes as an ordered patch series, one purpose per patch, as ungoogled-chromium does with its patches/ directory.
• Let Git remember conflict resolutions. With git rerere enabled, a conflict you have already resolved is resolved the same way next time.
• Put features behind flags. Chromium’s base::Feature flags let you turn a misbehaving change off without rebuilding the browser.
• Automate the mechanical part. Fetch with depot_tools (gclient sync), apply the series, then build and run tests in CI on every platform.
• Track two numbers per rebase: how many upstream files your patches touch, and how many engineer-hours the rebase took. When either keeps rising, the patch series needs work.

Why internal APIs are the recurring problem

Chromium keeps web platform APIs stable but refactors its internal C++ interfaces freely. A patch that hooks into a class, function signature or file that gets renamed will not appear in any changelog. It stops compiling on the next rebase or, worse, compiles and behaves differently.

What reduces this cost over time

• Hooking at narrow, more stable extension points instead of deep inside a module’s internals, where that option exists.
• Documenting why each patch exists and which upstream behavior it changes, so a rebase does not depend on one engineer remembering the original intent.
• Keeping each patch small and single-purpose, so a conflict in one area does not block unrelated patches from applying cleanly.

Keep the toolchain current

Chromium pins its own Clang and Rust toolchains, which are downloaded with the source, and it periodically raises the Xcode and Windows SDK versions it needs. Update CI images and build machines before a rebase, not in the middle of one.

Security backports cannot wait for the next rebase

Browsers are a frequent target, and Chrome regularly ships fixes for actively exploited issues. Its release notes say when Google is aware that an exploit exists in the wild. The time between upstream publishing a fix and your fork shipping it is your patch gap, and published fixes show attackers where to look. Backport in-the-wild fixes within days. A workable plan names who watches upstream security advisories, how quickly a patched build can be produced outside the normal cycle, and how it reaches installed users.

What changes for Firefox forks

The overall shape is the same (rebase a patch series onto a new upstream tag), but the details differ. Firefox ships a new major version every four weeks, and its Extended Support Release (ESR) gives a longer-lived base that keeps receiving security fixes; Tor Browser, for example, is built on ESR. The build uses Mozilla’s mach tool, and Gecko’s internals differ from Chromium’s throughout, so porting experience in one engine does not transfer directly to the other. See our Firefox browser modification service.

What a maintenance plan should include

• A defined rebase cadence: every Chrome release, or Extended Stable milestones.
• An owner responsible for tracking upstream security advisories between rebases.
• Automated builds and smoke tests that run on every supported platform after each rebase.
• Written documentation for each patch: what it does, why it exists, and what upstream behavior it changes.
• A tested update channel, so a rebased or backported build reaches users without a manual download.

For an example, our GTX Browser work included moving a fork with IPFS, a custom gtx:// protocol and a built-in wallet from Chromium 98 to 114. The same discipline is described in our guide to Chromium, and it is the work covered by our version porting and upstream maintenance service.

Already several versions behind? Start with a gap assessment: how many versions, how many conflicting patches, and which security fixes are missing.