ul
Padre Harmon
A partial list of changes is available in the Git log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Hi, everyone! We've just released Chrome 120 (120.0.6099.43) for Android to a small percentage of users. It'll become available on Google Play over the next few days. You can find more details about early Stable releases here.
The Stable channel has been updated to 120.0.6099.56 for Windows and Mac as part of our early stable release to a small percentage of users. A full list of changes in this build is available in the log.
Chrome supports a number of different release channels. We use these channels toslowly roll out updates to users, starting with our close to daily Canarychannel builds, all the way up to our Stable channel releases that happen every6 weeks roughly.
The release channels for chrome range from the most stable and tested (Stablechannel) to completely untested and likely least stable (Canary channel). Youcan run all channels alongside all others, as they do not share profiles withone another. This allows you to play with our latest code, while still keeping atested version of Chrome around.
Note: Early access releases (Canary builds and Dev and Beta channels) willbe only partly translated into languages other than English. Text related to newfeatures may not get translated into all languages until the feature is releasedin the Stable channel.
Later this year, we plan to shorten the release cycle and ship a new version of Google Chrome to the stable channel every four weeks, down from the current six-week cycle. There's more detail on the Chromium Blog about the impetus and rationale for this change.
One of my favorite aspects of being a web developer is the ease of deployment. I can fix a critical bug and deploy it to all of my users quickly. Moving to a four-week release cycle will give us more agility to get critical security and bug fixes out to users faster. And for developers, you won't have to wait as long for updates and bug fixes.
Shifting to a faster release cycle allows us to experiment and iterate on new features more effectively via origin trials, without having to wait as long between releases. It doesn't mean we'll be shipping more features, or shipping new features in less time. And it doesn't change the way we ship new features. We remain committed to working with standards bodies, our developer community, and the Chromium ecosystem.
Our current plan is for Chrome 94 to be the first release on the new four-week schedule, and it will be released on September 21st, 2021 (instead of October 12th, 2021). Each subsequent release will take place four weeks later. Thus, Chrome 93 (August 31st, 2021) will be the last release on the six-week schedule. We've updated our release calendar so you can see the updated dates.
Today, it can take upwards of 2 weeks for the majority of users to move to the latest stable release. We believe that the four-week release cycle will allow us to more consistently move the majority of users to the latest stable release within 2 weeks. Of course, it's always a good idea to check the analytics for your site to understand how fast your users upgrade to the latest stable. In some scenarios, it may be longer.
We chatted with Technical Program Managers Ben Henry, Krishna Govind, Harry Souders, Srinivas Sista, and Brandon Heenan on the Chrome release team for an inside look at how they coordinate with Google teams across the world to ensure each release goes smoothly.
Krishna: We make sure to gradually roll out new Chrome releases to users. New releases aren't immediately pushed to 100% of users. If we find a critical bug, we halt the roll out of the affected versions to limit its effects. We then coordinate with Chrome teams around the world to develop a fix and patch Chrome as quickly and safely as possible. Once this fix has been verified, we build a new version of Chrome and start the roll out process again. At the end of the day, most users will never experience the issue because it will have been fixed before the release ever rolled out to them. For security issues, we follow the Project Zero Disclosure policy. So when there are vulnerabilities being actively exploited in the wild, we have a goal of releasing that fix to our stable channel users within seven days.
Brandon: One of our top goals is ensuring that Chrome remains a stable, reliable platform for the many businesses that depend on us. That means giving businesses access to the best and latest functionality that they want their people to take advantage of, while helping them avoid any potential disruptions to their work. Because the needs of business are unique and any downtime can hurt an enterprise, Chrome has specific guidance for our engineering and product teams, and we review each feature launch to ensure that every Chrome release is "enterprise-friendly." That includes giving companies a heads up to important changes in our Chrome Enterprise Release Notes. And for added peace of mind, IT admins can control many changes with an enterprise policy. So, if they prefer to do internal testing, or opt out of a new feature, they can do just that. To prevent unexpected issues, we have a dedicated testing infrastructure designed to simulate enterprise environments (for example, running Chrome on Active Directory domain-joined devices) that we use to test all Chrome releases.
Chrome also provides a range of update controls to schools and businesses. Admins can control Chrome's specific version, rollback to older versions, and take advantage of our fully-supported extended stable release channel. You can read about the details in this technical document. Admins that want full visibility into the update status of their fleet can use the Version Report included in Chrome Browser Cloud Management.
Harry: We're always looking for ways to improve Chrome for our users and developers, especially when it comes to shortening the release cycle. By doing so, users will see a more stable Chrome with faster bug fixes and new features. We also know that our engineers and product managers benefit from increased development velocity due to faster feature development, faster iteration cycles, and increased code health. Let's say a product manager wants to launch a feature to all Chrome users. It can take up to 16 weeks from when the feature is "done" to when it's generally available. By shortening the release cycle by just a couple of weeks, we can significantly reduce the lead time to launch a new feature.
A series of versions of Chrome is deployed within each release channel, as updates, improvements, and bug fixes are incorporated during testing. For each channel, the version keeps the same major version number throughout one release cycle. For example, when this article was drafted, Chrome Stable was on version 101, Chrome Beta was 102, Chrome Dev and Chrome Canary were different versions of 103. You'll sometimes see these major numbers referred to as milestones: for example, M101 or M102.
If you're curious about the version you're using, take a look at the chrome://version page. You can observe how the version number changes over time for each channel. You can check the latest versions for each Chrome release channel and platform at omahaproxy.appspot.com. This site also provides tools to view code differences between versions.
Chrome has thousands of contributors, millions of lines of code, and billions of users. Widely-used, complex software needs robust processes and strict testing mechanisms to ensure that new features and changes to code avoid adding bugs and causing unexpected side effects. Chrome engineers continue to test after Stable release, when real people start using the browser at scale.
Components can be updated without requiring a new version of Chrome to be installed. This allows updates to be deployed more quickly, outside of release channel schedules, without needing the browser to be relaunched. That's particularly important for security features and can reduce the size of the Chrome installer for new versions.
This initial release of WebGPU serves as a building block for future updates and enhancements. The API will offer more advanced graphics features, and developers are encouraged to send requests for additional features. The Chrome team also plans to provide deeper access to shader cores for even more machine learning optimizations and additional ergonomics in WGSL, the WebGPU Shading Language.
This initial release of WebGPU is available in Chrome 113 on ChromeOS devices with Vulkan support, Windows devices with Direct3D 12 support, and macOS. Linux, Android, and expanded support for existing platforms will come soon.
aa06259810