Chrome pushes a new stable version to the public every 6 weeks while taking 7 weeks to stabilize the beta branch.
2 weeks before the branch point, the feature freeze is declared! Any feature planned to launch with this milestone should be code-complete (its implementation should be done) and enabled on Trunk/Canary so that the test team can give initial feedback. By the feature freeze, all strings must be landed!
Every 6 weeks, the latest canary is declared as the new milestone stabilization branch with a number (used as the branch name) associated with it. The feature enhancement should be completed by the branch point and all ReleaseBlock-Beta bugs should be fixed. Avoid committing big and risky changes close to the branch point!
2 weeks after the branch point, the first beta release is pushed. All disabled tests associated with the release milestone should be completely addressed. New beta builds are pushed weekly until the stable release.
The Thursday before the stable release date, the last build from the beta branch is cut as the release build. All ReleaseBlock-Stable bugs should be fixed by the stable cut, which consequently corresponds to the absolute last date a merge to the release branch should be taken for inclusion in the initial stable release. The stable cut will, unless there are exceptions, use the final beta as its basis. For Chrome OS, the stable cut date may be different than the rest of Chrome.
7 weeks after the branch point a new major version is released. The stable rollout is staged over time so that any issues can be detected early and addressed before they reach all users. Each Chrome platform has a different stable rollout plan and the schedule below can vary based on circumstances:
A stable refresh is defined as a release of a new Chrome build outside of the normal release schedule to fix critical bugs detected during the stable rollout. Except for extremely critical issues (e.g. security or privacy escalations), a Chrome stable refresh should not be pushed more than 2 weeks after the initial build has been released to the public. In this case, we should consider punting any detected production issues to the next release.
For more information, see these guidelines for considering branch dates in project planning.