Microsoft will move Microsoft Edge Stable to a two-week major-version release cycle across supported platforms beginning with Edge 152, currently expected on August 27, 2026, while leaving its enterprise-focused Stable Extended channel on the existing eight-week schedule. The company is not promising twice as many browser changes so much as twice as many release trains. That distinction matters, because the browser is now infrastructure: a security boundary, an application runtime, an identity surface, and, increasingly, a delivery vehicle for Microsoft’s AI ambitions.
The move looks modest if you read it as a calendar tweak. It looks more consequential if you read it as Microsoft conceding that the old monthly browser milestone is no longer fast enough for Chromium’s center of gravity. Edge is not just following Chrome’s lead; it is accepting Chrome’s tempo as the default rhythm of the modern web.
The official pitch is deliberately calm. Microsoft says smaller, steadier releases should make change easier to absorb because each milestone carries roughly half as much new content as before. In theory, administrators see fewer giant bundles, users see less dramatic churn, and fixes arrive sooner.
That is the optimistic version of the story, and it is not wrong. A browser release that contains fewer moving parts can be easier to validate, easier to roll back from, and easier to explain to support desks. Anyone who has watched a seemingly routine browser update break authentication, printing, GPU acceleration, or a line-of-business web app understands the value of smaller blast radiuses.
But a faster release cycle also changes the implied contract between vendor and customer. The monthly browser milestone gave enterprises a recognizable checkpoint, even if security patches already landed between major releases. A two-week cadence asks organizations to make validation a continuous habit rather than a monthly ritual.
That is the larger cultural change. Microsoft is telling Windows shops that Edge will behave less like a traditional desktop application and more like a cloud service with a local executable attached.
That alignment is practical. Edge depends on Chromium, and Chromium’s security fixes, rendering changes, JavaScript engine updates, and web platform work arrive according to a cadence that Microsoft cannot fully dictate. Edge can differentiate with enterprise management, Microsoft account integration, Copilot features, vertical tabs, shopping tools, PDF handling, and Windows tie-ins, but the engine room still follows Chromium physics.
This is the bargain Microsoft made when it rebuilt Edge on Chromium. The browser gained compatibility, developer goodwill, and a realistic shot at relevance after the old EdgeHTML strategy failed to dislodge Chrome. The price was that Microsoft no longer controls the deepest part of the schedule.
That does not make Edge a mere Chrome skin. Microsoft adds policy surfaces, security controls, UI decisions, and Windows integration that matter a great deal in managed environments. But when Google changes the release metabolism of Chromium-era browsing, Microsoft has strong incentives to move with it rather than ask customers to live on a delayed fork of the web.
A two-week major cadence does not eliminate emergency patches. It does, however, reduce the maximum waiting time for non-emergency fixes and platform hardening that can safely ride the normal train. If a bug is not being actively exploited but is still meaningful, the difference between “next month” and “next release in two weeks” matters.
This is especially relevant because browser security is no longer just about the browser. Edge is tied into Microsoft Defender SmartScreen, identity flows, Entra ID sign-ins, device compliance checks, WebView2-based applications, and cloud-delivered services. A faster Edge train can therefore move improvements into a broad Windows estate without waiting for the slower Windows feature-update machinery.
The uncomfortable truth is that attackers already operate on a faster cadence than most enterprise testing processes. Microsoft is not accelerating Edge because users are clamoring for more sidebar tweaks. It is accelerating Edge because the browser has become too strategic, too exposed, and too tightly connected to cloud services to move like boxed software.
The best-run IT departments will adapt because many already treat browsers as evergreen infrastructure. They use rings, pilot groups, endpoint management, update deferrals, and telemetry to detect breakage early. For them, smaller and more frequent Edge releases may be easier to digest than larger monthly drops.
The harder case is the organization that still thinks of browser testing as an occasional certification event. Those environments may discover that the calendar itself has become the pressure point. A two-week cadence leaves less room for committees, manual smoke tests, and sprawling approval chains.
Microsoft knows this, which is why Stable Extended remains the escape hatch. The eight-week option is not going away, and for highly regulated environments or brittle application estates, it may become more attractive. The implicit message is clear: if you want the fast lane, Microsoft will make it smaller and steadier; if you need the slow lane, Microsoft will still sell you time.
Stable Extended exists for customers that need longer validation windows. In practice, that often means hospitals, banks, government agencies, manufacturing floors, call centers, and companies with old intranet applications that have survived three browser eras by becoming nobody’s favorite problem. These are not theoretical users. They are the reason enterprise software moves carefully even when consumer software moves quickly.
The tension is that Stable Extended also means delayed feature delivery. That may not matter much for UI changes, but it can matter for platform behavior, management controls, and security improvements that are not delivered as emergency fixes. Administrators choosing the longer track will have to decide whether predictability is worth the lag.
This is where Microsoft’s messaging about “smaller, steadier change” becomes more than marketing. If the two-week Stable channel proves reliable, some organizations may feel less need to hide behind the eight-week train. If it proves noisy, Stable Extended will become a refuge, and Microsoft’s faster cadence will look like another example of consumer-speed software colliding with enterprise reality.
That is not unique to Edge. Chrome already trained users to treat version numbers as background noise, and Firefox’s rapid-release era did the same years ago. The web won that argument: compatibility and security matter more than the ceremonial weight of a version number.
For developers, this means more pressure to test continuously against Beta and Stable rather than assume that a monthly milestone is the natural unit of change. Web APIs, rendering behavior, enterprise policies, deprecations, and security restrictions can all move faster when the train comes twice as often. The change does not necessarily mean more volatility, but it does mean less excuse for slow feedback loops.
For ordinary users, the major-version number may become almost invisible. Edge will update, restart, and continue. The visible browser will be defined less by version names and more by the moments when Microsoft changes defaults, promotes Copilot, adjusts privacy prompts, modifies extension behavior, or exposes a new Windows integration.
The problem is that browsers occupy a more sensitive position than chat apps. A browser mediates work credentials, financial sessions, corporate SaaS data, personal browsing, extensions, and downloads. When Microsoft adds AI features to Edge, it is not merely adding another button; it is changing what users may believe the browser can see, summarize, transmit, or act upon.
A faster release cycle gives Microsoft more room to iterate on those experiences. It also gives administrators more reason to scrutinize policy controls. The organizations that were already carefully managing Copilot availability, data boundaries, and browser sign-in behavior will need to watch Edge release notes more frequently.
This is the double edge of evergreen software. The same mechanism that pushes security improvements faster can also push controversial product integrations faster. Edge’s cadence is not just a patching story; it is a distribution story for Microsoft’s next wave of browser-based services.
Edge has become better at background updating, session restore, sleeping tabs, and preserving state across restarts. Still, a browser restart in the middle of a workday feels different from an app updating overnight. The more often Edge moves major versions, the more important Microsoft’s restart choreography becomes.
There is a trust dimension here. Users tolerate frequent updates when they believe the updates are protecting them or improving performance. They resent them when they suspect the changes are mostly promotional, cosmetic, or designed to surface services they did not ask for.
That is why Microsoft’s execution matters more than the schedule announcement. If the two-week cycle mostly feels like quiet security, compatibility, and performance work, users will forget it exists. If it coincides with more aggressive prompts, more sidebar reshuffling, or more default nudges, the faster cadence will become another symbol of software that will not sit still.
The first priority is update ring discipline. A small pilot group should see new Edge Stable releases before the broad fleet does, and that group should include users who exercise the company’s most important web apps. Browser validation should not be limited to whether the homepage loads.
The second priority is policy review. Edge has a deep enterprise policy surface, and faster releases can introduce new settings, deprecate old ones, or alter default behavior around security, identity, extensions, and user experience. Administrators who only revisit browser policy during crises will be perpetually behind.
The third priority is communication. Help desks need to know when Edge changes are expected, what symptoms matter, and when an issue is likely tied to the browser rather than the SaaS application being used inside it. In many organizations, “the website is broken” is now a browser operations ticket in disguise.
The good news is that closer alignment across Chromium-based browsers can reduce surprises. If Edge and Chrome are moving on similar schedules, developers have a clearer sense of when rendering and platform changes may reach users. The bad news is that the schedule leaves less time for reactive testing after a change appears in Stable.
The responsible workflow is to pay more attention to Beta. Microsoft and Google both want developers to test before Stable because the whole model depends on problems being found upstream. If most developers wait until the stable release hits production users, a two-week cadence simply accelerates the complaint cycle.
This is where automated testing becomes less optional. Browser farms, Playwright suites, synthetic monitoring, accessibility checks, and login-flow tests are no longer luxuries for large web properties. When the client runtime updates every two weeks, continuous validation is the only sane answer.
But release schedules are product strategy made visible. They reveal what a vendor thinks customers can absorb, how quickly threats must be answered, and where the vendor believes the market is moving. By shifting Edge Stable to two weeks, Microsoft is saying the browser can no longer wait a month to turn the crank.
The risk is that speed becomes a substitute for clarity. Faster release trains are only useful if release notes, policy documentation, rollback options, and management tooling keep pace. Enterprise customers do not merely need updates sooner; they need to understand what those updates change.
Microsoft has a mixed reputation on that front. Its enterprise documentation is often detailed, but its consumer-facing product behavior can feel abrupt, especially when defaults, prompts, or integrations shift. Edge’s new cadence will reward transparency and punish surprise.
For WindowsForum readers, the concrete implications are straightforward:
The move looks modest if you read it as a calendar tweak. It looks more consequential if you read it as Microsoft conceding that the old monthly browser milestone is no longer fast enough for Chromium’s center of gravity. Edge is not just following Chrome’s lead; it is accepting Chrome’s tempo as the default rhythm of the modern web.
Microsoft Chooses Velocity Without Calling It Disruption
The official pitch is deliberately calm. Microsoft says smaller, steadier releases should make change easier to absorb because each milestone carries roughly half as much new content as before. In theory, administrators see fewer giant bundles, users see less dramatic churn, and fixes arrive sooner.That is the optimistic version of the story, and it is not wrong. A browser release that contains fewer moving parts can be easier to validate, easier to roll back from, and easier to explain to support desks. Anyone who has watched a seemingly routine browser update break authentication, printing, GPU acceleration, or a line-of-business web app understands the value of smaller blast radiuses.
But a faster release cycle also changes the implied contract between vendor and customer. The monthly browser milestone gave enterprises a recognizable checkpoint, even if security patches already landed between major releases. A two-week cadence asks organizations to make validation a continuous habit rather than a monthly ritual.
That is the larger cultural change. Microsoft is telling Windows shops that Edge will behave less like a traditional desktop application and more like a cloud service with a local executable attached.
Chrome Sets the Pace, Edge Makes the Compromise
The timing is not accidental. Google announced earlier this year that Chrome would move to a two-week stable release cycle starting with Chrome 153 in September 2026. Microsoft’s plan starts with Edge 152 in late August, putting Edge on roughly the same accelerated track as the Chromium project’s most influential browser.That alignment is practical. Edge depends on Chromium, and Chromium’s security fixes, rendering changes, JavaScript engine updates, and web platform work arrive according to a cadence that Microsoft cannot fully dictate. Edge can differentiate with enterprise management, Microsoft account integration, Copilot features, vertical tabs, shopping tools, PDF handling, and Windows tie-ins, but the engine room still follows Chromium physics.
This is the bargain Microsoft made when it rebuilt Edge on Chromium. The browser gained compatibility, developer goodwill, and a realistic shot at relevance after the old EdgeHTML strategy failed to dislodge Chrome. The price was that Microsoft no longer controls the deepest part of the schedule.
That does not make Edge a mere Chrome skin. Microsoft adds policy surfaces, security controls, UI decisions, and Windows integration that matter a great deal in managed environments. But when Google changes the release metabolism of Chromium-era browsing, Microsoft has strong incentives to move with it rather than ask customers to live on a delayed fork of the web.
The Security Argument Is Stronger Than the Feature Argument
Microsoft’s most defensible case is security. Browsers are among the most exposed pieces of software on any Windows PC because they process hostile content all day by design. Every tab is a potential parser test, every extension is a trust decision, and every web app is another reason the browser has become the operating system’s most important application runtime.A two-week major cadence does not eliminate emergency patches. It does, however, reduce the maximum waiting time for non-emergency fixes and platform hardening that can safely ride the normal train. If a bug is not being actively exploited but is still meaningful, the difference between “next month” and “next release in two weeks” matters.
This is especially relevant because browser security is no longer just about the browser. Edge is tied into Microsoft Defender SmartScreen, identity flows, Entra ID sign-ins, device compliance checks, WebView2-based applications, and cloud-delivered services. A faster Edge train can therefore move improvements into a broad Windows estate without waiting for the slower Windows feature-update machinery.
The uncomfortable truth is that attackers already operate on a faster cadence than most enterprise testing processes. Microsoft is not accelerating Edge because users are clamoring for more sidebar tweaks. It is accelerating Edge because the browser has become too strategic, too exposed, and too tightly connected to cloud services to move like boxed software.
Enterprise IT Gets a Smaller Package More Often
For administrators, the change is a trade. Microsoft’s claim that each release will contain about half as much change is meaningful, but it does not erase the operational burden of more frequent milestones. Every new major version can trigger compatibility testing, change review, help-desk preparation, policy review, and internal communications.The best-run IT departments will adapt because many already treat browsers as evergreen infrastructure. They use rings, pilot groups, endpoint management, update deferrals, and telemetry to detect breakage early. For them, smaller and more frequent Edge releases may be easier to digest than larger monthly drops.
The harder case is the organization that still thinks of browser testing as an occasional certification event. Those environments may discover that the calendar itself has become the pressure point. A two-week cadence leaves less room for committees, manual smoke tests, and sprawling approval chains.
Microsoft knows this, which is why Stable Extended remains the escape hatch. The eight-week option is not going away, and for highly regulated environments or brittle application estates, it may become more attractive. The implicit message is clear: if you want the fast lane, Microsoft will make it smaller and steadier; if you need the slow lane, Microsoft will still sell you time.
Stable Extended Becomes the Safety Valve Microsoft Needs
The decision to keep Stable Extended unchanged is not a footnote. It is the political mechanism that makes the faster Stable cadence viable. Without it, Microsoft would be forcing every managed Edge environment into a rhythm that some organizations simply cannot meet.Stable Extended exists for customers that need longer validation windows. In practice, that often means hospitals, banks, government agencies, manufacturing floors, call centers, and companies with old intranet applications that have survived three browser eras by becoming nobody’s favorite problem. These are not theoretical users. They are the reason enterprise software moves carefully even when consumer software moves quickly.
The tension is that Stable Extended also means delayed feature delivery. That may not matter much for UI changes, but it can matter for platform behavior, management controls, and security improvements that are not delivered as emergency fixes. Administrators choosing the longer track will have to decide whether predictability is worth the lag.
This is where Microsoft’s messaging about “smaller, steadier change” becomes more than marketing. If the two-week Stable channel proves reliable, some organizations may feel less need to hide behind the eight-week train. If it proves noisy, Stable Extended will become a refuge, and Microsoft’s faster cadence will look like another example of consumer-speed software colliding with enterprise reality.
The Browser Version Number Is Becoming Less Meaningful
There is also a psychological shift here. When major versions arrive every two weeks, the word “major” starts to lose some of its old meaning. Edge 152, 153, 154, and 155 will not feel like four dramatic product generations; they will feel like markers on a conveyor belt.That is not unique to Edge. Chrome already trained users to treat version numbers as background noise, and Firefox’s rapid-release era did the same years ago. The web won that argument: compatibility and security matter more than the ceremonial weight of a version number.
For developers, this means more pressure to test continuously against Beta and Stable rather than assume that a monthly milestone is the natural unit of change. Web APIs, rendering behavior, enterprise policies, deprecations, and security restrictions can all move faster when the train comes twice as often. The change does not necessarily mean more volatility, but it does mean less excuse for slow feedback loops.
For ordinary users, the major-version number may become almost invisible. Edge will update, restart, and continue. The visible browser will be defined less by version names and more by the moments when Microsoft changes defaults, promotes Copilot, adjusts privacy prompts, modifies extension behavior, or exposes a new Windows integration.
Microsoft’s AI Browser Ambitions Need a Faster Train
It would be naïve to discuss Edge’s release cadence without mentioning AI. Microsoft has spent the last several years turning Edge into one of the company’s most prominent surfaces for Copilot, summarization, shopping assistance, writing help, and contextual productivity features. Those features live in a market where product expectations change at cloud speed.The problem is that browsers occupy a more sensitive position than chat apps. A browser mediates work credentials, financial sessions, corporate SaaS data, personal browsing, extensions, and downloads. When Microsoft adds AI features to Edge, it is not merely adding another button; it is changing what users may believe the browser can see, summarize, transmit, or act upon.
A faster release cycle gives Microsoft more room to iterate on those experiences. It also gives administrators more reason to scrutinize policy controls. The organizations that were already carefully managing Copilot availability, data boundaries, and browser sign-in behavior will need to watch Edge release notes more frequently.
This is the double edge of evergreen software. The same mechanism that pushes security improvements faster can also push controversial product integrations faster. Edge’s cadence is not just a patching story; it is a distribution story for Microsoft’s next wave of browser-based services.
Windows Users Will Notice the Restarts Before the Strategy
For home users, the most visible effect may be mundane: more frequent prompts to restart the browser. Microsoft argues that each release will be smaller, and that may be true, but users rarely judge updates by diff size. They judge them by interruption.Edge has become better at background updating, session restore, sleeping tabs, and preserving state across restarts. Still, a browser restart in the middle of a workday feels different from an app updating overnight. The more often Edge moves major versions, the more important Microsoft’s restart choreography becomes.
There is a trust dimension here. Users tolerate frequent updates when they believe the updates are protecting them or improving performance. They resent them when they suspect the changes are mostly promotional, cosmetic, or designed to surface services they did not ask for.
That is why Microsoft’s execution matters more than the schedule announcement. If the two-week cycle mostly feels like quiet security, compatibility, and performance work, users will forget it exists. If it coincides with more aggressive prompts, more sidebar reshuffling, or more default nudges, the faster cadence will become another symbol of software that will not sit still.
Sysadmins Should Treat Edge Like a Service Dependency
The practical response for IT departments is not panic. It is process. Edge is already too important to be managed casually, and the new cadence merely makes that fact harder to ignore.The first priority is update ring discipline. A small pilot group should see new Edge Stable releases before the broad fleet does, and that group should include users who exercise the company’s most important web apps. Browser validation should not be limited to whether the homepage loads.
The second priority is policy review. Edge has a deep enterprise policy surface, and faster releases can introduce new settings, deprecate old ones, or alter default behavior around security, identity, extensions, and user experience. Administrators who only revisit browser policy during crises will be perpetually behind.
The third priority is communication. Help desks need to know when Edge changes are expected, what symptoms matter, and when an issue is likely tied to the browser rather than the SaaS application being used inside it. In many organizations, “the website is broken” is now a browser operations ticket in disguise.
Web Developers Lose Another Excuse for Slow Testing
Developers are another audience Microsoft is implicitly addressing. A two-week Edge cadence, aligned with Chrome’s faster train, means the compatibility window moves faster for everyone building for the web. That includes enterprise developers maintaining internal apps, not just public websites chasing the latest CSS feature.The good news is that closer alignment across Chromium-based browsers can reduce surprises. If Edge and Chrome are moving on similar schedules, developers have a clearer sense of when rendering and platform changes may reach users. The bad news is that the schedule leaves less time for reactive testing after a change appears in Stable.
The responsible workflow is to pay more attention to Beta. Microsoft and Google both want developers to test before Stable because the whole model depends on problems being found upstream. If most developers wait until the stable release hits production users, a two-week cadence simply accelerates the complaint cycle.
This is where automated testing becomes less optional. Browser farms, Playwright suites, synthetic monitoring, accessibility checks, and login-flow tests are no longer luxuries for large web properties. When the client runtime updates every two weeks, continuous validation is the only sane answer.
The Calendar Is Now Part of the Security Model
Microsoft’s Edge announcement is easy to underestimate because it sounds administrative. Release schedules are not flashy. They do not demo well. They rarely get the attention lavished on AI features, new hardware, or Windows UI changes.But release schedules are product strategy made visible. They reveal what a vendor thinks customers can absorb, how quickly threats must be answered, and where the vendor believes the market is moving. By shifting Edge Stable to two weeks, Microsoft is saying the browser can no longer wait a month to turn the crank.
The risk is that speed becomes a substitute for clarity. Faster release trains are only useful if release notes, policy documentation, rollback options, and management tooling keep pace. Enterprise customers do not merely need updates sooner; they need to understand what those updates change.
Microsoft has a mixed reputation on that front. Its enterprise documentation is often detailed, but its consumer-facing product behavior can feel abrupt, especially when defaults, prompts, or integrations shift. Edge’s new cadence will reward transparency and punish surprise.
Edge’s New Rhythm Leaves IT With Fewer Comfortable Myths
The immediate lesson is not that everyone should flee to Stable Extended or embrace every two-week build without hesitation. The lesson is that browser management has become a first-class operational discipline. Edge is now too central to Windows work to be treated as a passive accessory.For WindowsForum readers, the concrete implications are straightforward:
- Edge Stable is scheduled to move to a two-week major-version cadence with Edge 152 on August 27, 2026.
- Microsoft says each Stable release should contain a smaller change set, not twice the total monthly volume of features.
- Stable Extended remains on its eight-week schedule for managed environments that need longer validation windows.
- The shift aligns Edge more closely with Chrome’s move to a two-week release cycle beginning with Chrome 153 in September 2026.
- Administrators should tighten pilot rings, browser policy review, and web-app regression testing before the new cadence arrives.
- Users may not notice more features, but they may notice the operational side effects of a browser that asks to restart and evolve more often.
References
- Primary source: Windows Central
Published: Thu, 11 Jun 2026 20:46:33 GMT
Major Microsoft Edge versions will now ship every two weeks: Microsoft confirms plans to ship new Edge features and changes twice a month | Windows Central
Microsoft has announced that Edge will be moving to a two-week release cycle for major versions of the browser, matching Chrome.www.windowscentral.com - Official source: learn.microsoft.com
Microsoft Edge release schedule | Microsoft Learn
Microsoft Edge release schedulelearn.microsoft.com - Related coverage: phoronix.com
Google Chrome Moving To A Two-Week Release Cycle - Phoronix
Google announced today that beginning later this year they are moving the Chrome web browser from its four week release cycle down to a two week release cadence.www.phoronix.com
- Related coverage: techspot.com
Google will start shipping a new Chrome version every two weeks | TechSpot
Google has announced a notable shift in how Chrome updates will roll out. Starting September 2026, the Chromium-based browser will move to a two-week release cycle. In...www.techspot.com - Official source: 9to5google.com
Google Chrome is switching to a two-week release cycle
Google will soon release a major update for its Chrome browser on all platforms every four weeks to "get features [out] faster."9to5google.com - Related coverage: helpnetsecurity.com
Google speeds up Chrome updates with new security-focused release cycle - Help Net Security
The Chrome browser is moving to a two-week release cycle, a change intended to give developers and users faster access to new features.www.helpnetsecurity.com
- Related coverage: androidauthority.com
Google speeds up Chrome release schedule with new stable build every two weeks
Google is speeding up its stable release schedule for its Chrome browser from every four to every two weeks.www.androidauthority.com - Related coverage: startupnews.fyi
- Related coverage: scworld.com
Google Chrome accelerates release cycle to bi-weekly updates | brief | SC Media
The new bi-weekly release cadence will apply to both beta and stable versions of Chrome on Desktop, Android, and iOS.www.scworld.com - Related coverage: superchargebrowser.com
Chrome's 2-Week Release Cycle (Sept 2026): What Changes
Chrome 153 starts a 2-week release cadence on Sept 8, 2026. Security patches arrive faster, extensions break more often. Enterprise Extended Stable unchanged.www.superchargebrowser.com
- Related coverage: angeles.ccn-cert.cni.es
- Related coverage: thurrott.com
Google Moves Chrome to a Two-Week Development Schedule - Thurrott.com
Starting with Chrome 153 in September 2026, Google will move its web browser to a two-week development schedule.www.thurrott.com - Related coverage: tech.slashdot.org
Google Chrome Is Switching To a Two-Week Release Cycle - Slashdot
Google is accelerating Chrome's major release cadence from four weeks to two starting with version 153 on September 8th. "...our goal is to ensure developers and users have immediate access to the latest performance improvements, fixes and new capabilities," says Google. "Building on our history...tech.slashdot.org - Related coverage: ubos.tech
Google Chrome Shifts to a Two‑Week Release Cycle - UBOS
Google Chrome will now ship stable updates every two weeks, halving the previous six‑week cadence. This accelerated release schedule is designed to deliver security patches, performance improvements, and new features to users and developers faster than ever before. Why the change matters for...ubos.tech - Related coverage: hashe.com
Google Chrome Is Switching To A Two-week Release Cycle
google chrome is switching to a two-week: Google has announced a significant change to its Chrome browser update schedule, moving to a two-week release cyclewww.hashe.com - Related coverage: valuesense.io
Google (GOOGL) Accelerates Chrome Updates to Two-Week Cycle in September - ValueSense
Alphabet Inc. (NASDAQ: GOOGL), the parent company of Google, announced on March 4, 2026, that it will accelerate the release cycle for its popular Chrome browse...valuesense.io - Related coverage: tech.yahoo.com
Google Chrome is speeding up its release cycle, again
A Chrome update every two weeks.tech.yahoo.com - Related coverage: ivy.fm
Windows Weekly (MP3) | Ivy.fm
Podcast by TWiT. A weekly look at all things Microsoft, including Windows, Office, Xbox, and more, from two of the foremost Windows watchers in the world, Paul Thurrott of Thurrott.com and Mary Jo Foley of All About Microsoft. Records live every Wednesday at 2:00pm Eastern / 11:00am Pacific /...ivy.fm
