WebView2's 2-week cadence starts at version 153, not 152 - and three Microsoft pages still say 152

Summary. Microsoft published a post on 24 August 2026 saying the WebView2 Runtime moves to a 2-week major release cadence, and that version 152, shipping in the week of 27 August 2026, is the last major released four weeks after the previous one. Version 153, in the week of 10 September 2026, is the first on the new rhythm. Three other live Microsoft pages still name 152 as the pivot, including the pinned announcement issue opened on 1 July 2026 and the Runtime 151 release notes last updated on 14 August 2026. The number that matters for anyone shipping a WebView2 app is not the cadence itself but the Beta-to-Stable gap: Microsoft's own release schedule puts it at 15 to 16 days for versions 153 through 158, against exactly 21 days for every one of versions 147 through 152. The announcement issue tells developers the window is "now ~21 days (down from 28+)". That figure is the old window, not the new one.

What actually changed, and on which version

The WebView2 Runtime is the redistributable Chromium-based web platform behind Windows desktop apps that embed a browser control. Microsoft describes it as "a redistributable runtime" that "contains modified Microsoft Edge binaries that are fine-tuned and tested for WebView2 apps". It ships in two distribution modes: Evergreen, the default, which self-updates on the client; and Fixed Version, which you download and package inside your own installer.

Microsoft Edge is moving from a four-week major release cycle to a two-week one, and the WebView2 Runtime moves with it. That much every Microsoft page agrees on. The disagreement is about when.

The WebView2 blog post of 24 August 2026 is unambiguous: "On the week of August 27, the WebView2 Runtime version 152 will be last major version to be released 4 weeks after the previous version. On the week of September 10, version 153 will be the very first version to be released only two weeks after the previous version."

The Microsoft Edge release schedule backs this with dates. Edge 151 reached Stable on 31 July 2026. Edge 152 is targeted for the week of 27 August 2026, which is 27 days later, a four-week gap. Edge 153 lands in the week of 10 September, two weeks after that. The arithmetic on Microsoft's own table says 153 is the pivot.

Chromium says the same thing about itself. Ben Mason and Deepak Ravichandran of Chrome for Developers wrote on 3 March 2026 that "a new beta and stable version of Chrome will ship every two weeks, starting from the stable release of Chrome 153 on September 8th". Edge tracks Chromium version for version. If Chrome pivots at 153, Edge and WebView2 pivot at 153.

The three pages that still say 152

Six rows, two answers. The two current pages agree with each other and with the schedule table. The three older ones do not, and none of them carries a correction notice. The Runtime 151 release notes still read "Starting with version 152 (Aug. 24, 2026), the WebView2 Runtime moves to a 2-week release cadence", with a page footer stamped 14 August 2026 - eleven days before the blog post that contradicts it.

This is not a trivia point. If your release calendar was built in July from announcement issue #137, you have a validation sprint booked for the wrong fortnight, and a Fixed Version pickup planned for a major that is still on the old cadence.

The Beta window is 15 days, and the announcement says 21

Announcement issue #137 tells developers: "The Beta validation window is now ~21 days (down from 28+)." Both halves of that sentence fail against Microsoft's published schedule.

Twelve rows. Every version from 147 to 152 sits at exactly 21 days. Every version from 153 to 158 sits at 15 or 16, averaging 15.3. The window does not become "~21 days"; it was 21 days, and it becomes about 27 percent shorter. The "down from 28+" baseline appears nowhere in the schedule table, for any release going back to 2022.

If you run a validation cycle that takes three weeks of calendar time, it fitted the old cadence exactly and does not fit the new one at all. That is the change to plan around, and it is the one number the announcement gets wrong.

Support and servicing halve while the release count stays the same

The Microsoft Edge lifecycle page, stamped 11 June 2026, says: "We continue to provide Assisted Support for the most recent three Stable channel releases and the latest Beta channel release. The effective assisted support duration for a Stable channel release is approximately 6 weeks."

The count of three is unchanged. The duration is not. Three Stable releases at four weeks apart covered about twelve weeks. Three at two weeks apart cover the six the page now states. The same page's table puts Stable servicing coverage at 2 weeks, meaning only the current release is serviced, and the current release now lasts a fortnight.

Seven rows. The last two are where WebView2 teams get caught. Extended Stable keeps its eight-week rhythm and its roughly sixteen weeks of Assisted Support, which the lifecycle page confirms and the Edge blog of 11 June 2026 states as "Extended Stable remains unchanged in timing". But the lifecycle page also says Extended Stable releases are "published every fourth Stable release". Under the old cadence, an Extended Stable machine skipped one major. Under the new one it skips three: the schedule shows Extended Stable at 152 in the week of 27 August and then 156 in the week of 22 October, with 153, 154 and 155 absent.

The WebView2 documentation never mentions Extended Stable

Here is the part that matters if you both embed WebView2 and manage Edge. Search the four WebView2 pages that govern distribution and enterprise behaviour - evergreen vs fixed version, distribute your app and the WebView2 Runtime, enterprise management of WebView2 Runtimes, and the WebView2 release notes index - and the string "Extended Stable" occurs zero times across all four.

What the enterprise page does say is narrower: "Security updates and servicing updates are only available on the latest Stable channel release (Edge Stable) and the latest Beta channel release (Edge Beta)." Edge Stable and Edge Beta. No third option.

So an organisation that puts Edge on Extended Stable to buy itself an eight-week rhythm and sixteen weeks of Assisted Support does not get an Extended Stable WebView2 Runtime along with it. The Evergreen Runtime on those same machines follows Edge Stable and now turns over every two weeks. The enterprise page notes that Edge update policies apply to both the browser and the Runtime "unless the policy is channel-specific, such as Update and Update (WebView)", so the two are separable by policy - but there is no slower supported channel to separate the Runtime into. Suppressing updates is not an answer either: the page says the UpdatesSuppressed policy sets a daily window and that "after the time period, updating of the WebView2 Runtime resumes".

The practical result is a widening split inside one managed estate. The browser your IT team validates moves four times a year. The browser engine inside your line-of-business desktop apps now moves twenty-six times a year.

Fixed Version teams: the update budget doubles

The Fixed Version distribution mode is the escape hatch, and Microsoft is careful about how it describes it. The evergreen-vs-fixed-version page lists as a drawback: "You need to manage the WebView2 Runtime yourself. The WebView2 Runtime isn't automatically updated on clients, so to use the latest WebView2 APIs, you must periodically update your app together with the updated WebView2 Runtime." The 24 August blog adds: "you stay in control of when you update, but new major versions arrive more often. Plan to validate and pick up new versions more frequently, so you don't fall behind on security fixes."

"More often" means twice as often. A team that repackaged and reshipped its installer on every WebView2 major went from roughly 13 repackaging cycles a year to roughly 26. A team that picked up every second major to save effort was one major behind at worst; the same policy now leaves it two majors and four weeks behind, on a component whose servicing coverage is two weeks.

Runtime 151, released 3 August 2026, is a fair sample of what falling behind costs. Its release notes list bug fixes including "Stamped the browser-authoritative origin on the host pipe, to prevent a WebMessageReceivedEventArgs.Source spoof", "Hardened WebView2 virtual-host kDeny enforcement against renderer spoofing and New Technology File System (NTFS)-junction escapes", and "Restricted access to a singleton host pipe in legacy WebView2 clients". Those are host-boundary fixes in the layer between your native app and untrusted web content. The same release notes carry a separate recommendation to "Run your WebView2 host application at standard user integrity rather than elevated".

The real cost here is the release engineering, not the code. Nothing in your application changes. What changes is how many times a year your build, sign, test and distribute pipeline has to run to completion without a human in it.

What to do before 10 September 2026

Correct the pivot date first. Any internal plan citing 24 August 2026 or version 152 as the start of the two-week cadence came from a page that is now wrong; the first two-week release is 153, in the week of 10 September 2026.

Then size the gap between your validation cycle and 15 days. Microsoft's recommendation is to test against Beta and to automate it: the 24 August post says to test "by using the Beta preview channel of Microsoft Edge to catch any bugs before they roll out to your users", and to automate "the validation of your app's core workflows with the WebView2 preview channels" using Microsoft Edge WebDriver. If your WebView2 smoke suite is manual, a 15-day window is where it stops being viable. Teams working through the same arithmetic on the browser side will recognise the pattern from the Chrome two-week release cycle QA playbook, and the cadence question itself is the same one Node.js forced with one release per year and the Node 27 LTS upgrade cadence, only in the opposite direction.

If you ship Fixed Version, decide now whether you are picking up every major or every second one, and write down the servicing consequence of the answer. If you run Evergreen on a managed estate, check whether your Edge channel choice and your WebView2 exposure have quietly diverged; Extended Stable on the browser does not slow the Runtime down. And if your patch process is already tuned to a monthly Microsoft rhythm, as most are around Patch Tuesday triage, the WebView2 component no longer fits inside it.

India-specific considerations

For Indian product and services teams shipping Windows desktop software to overseas customers, the binding constraint is usually the validation calendar, not engineering capacity. A 15-day Beta-to-Stable window means roughly 26 validation passes a year landing on a team that may also be covering an offshore client's business hours. Automated WebView2 smoke testing through Microsoft Edge WebDriver is the only version of this that scales; a manual matrix does not survive twenty-six turns.

There is a compliance edge too. Where a WebView2 control renders personal data inside a desktop app, the host-boundary fixes in Runtime 151 sit directly on the path that the Digital Personal Data Protection Act 2023 would treat as a security safeguard obligation. Running an unserviced Runtime because your pickup cadence slipped is now a two-week exposure rather than a four-week one.

What is still unknown

Microsoft has not published Beta and Stable dates beyond version 158 in the week of 19 November 2026, so whether the 15-day pattern holds through the December holiday period is not yet on the schedule. Announcement #137 says WebView2 SDK releases move "away from a fixed monthly cadence" to an as-needed basis, and that "a new SDK release is not expected for every Runtime release", but no minimum SDK frequency is stated anywhere. And the three pages naming 152 as the pivot carry no correction, so it is not clear whether they will be revised before 10 September or simply age out.

FAQ

How eCorpIT can help

Most teams caught by this change do not have a WebView2 problem; they have a release engineering problem that a 15-day window exposes. eCorpIT builds and hardens the automated validation and packaging pipelines that make a fortnightly Chromium turnover survivable, including WebDriver-driven smoke suites for embedded browser controls and Fixed Version repackaging that runs without a human in the loop. Our senior engineering teams work under CMMI Level 5 and ISO 27001:2022 practices. If your desktop validation cycle is longer than fifteen days, book a release cadence review with our engineering team.

References

1. WebView2 is moving to a 2-week release cadence - Microsoft Edge Team, 24 August 2026

1. Announcement: WebView2 Runtime and SDK release cadence updates (starting v152) - MicrosoftEdge/WebView2Announcements issue #137, 1 July 2026

1. Microsoft Edge release schedule - Microsoft Learn

1. Microsoft Edge lifecycle policy - Microsoft Learn, updated 11 June 2026

1. Microsoft Edge channel overview - Microsoft Learn

1. Release notes for the WebView2 Runtime, version 151 - Microsoft Learn, 3 August 2026

1. Evergreen vs. fixed version of the WebView2 Runtime - Microsoft Learn

1. Distribute your app and the WebView2 Runtime - Microsoft Learn

1. Enterprise management of WebView2 Runtimes - Microsoft Learn

1. Release notes for WebView2 - Microsoft Learn

1. Get features faster with Chrome's two-week release cycle - Ben Mason and Deepak Ravichandran, Chrome for Developers, 3 March 2026

1. Faster updates, enterprise-friendly schedule: the new Microsoft Edge release cycle - Microsoft Edge Team, 11 June 2026

Last updated: 24 August 2026.