1# Chrome Release Cycle 2 3[TOC] 4 5## Overview 6 7Chrome pushes a new stable version to the public every 6 weeks while 8taking 7 weeks to stabilize the beta branch. 9 10## Schedule 11 12 13* Feature freeze and branch point dates are fixed, but release dates may change 14depending on the build quality. 15* There would be some adjustment in the release schedule due to Chrome no 16meeting weeks or holidays. 17 18## Key Dates 19 20### Feature Freeze 21 22**2 weeks** before the branch point, the feature freeze is declared! Any feature 23planned to launch with this milestone should be code-complete (its 24implementation should be done) and enabled on Trunk/Canary so that the test team 25can give initial feedback. By the feature freeze, all strings must be landed! 26 27### Branch Point 28 29**Every 6 weeks**, the latest canary is declared as the new milestone 30stabilization branch with a number (used as the branch name) associated with it. 31The feature enhancement should be completed by the branch point and all 32ReleaseBlock-Beta bugs should be fixed. Avoid committing big and risky changes 33close to the branch point! 34 35### First Beta 36 37**2 weeks** after the branch point, the first beta release is pushed. All 38disabled tests associated with the release milestone should be completely 39addressed. New beta builds are pushed weekly until the stable release. 40 41### Stable Cut 42 43The Thursday before the stable release date, the last build from the beta branch 44is cut as the release build. All ReleaseBlock-Stable bugs should be fixed by the 45stable cut, which consequently corresponds to the absolute last date a merge to 46the release branch should be taken for inclusion in the initial stable release. 47The stable cut will, unless there are exceptions, use the final beta as its 48basis. For Chrome OS, the stable cut date may be different than the rest of 49Chrome. 50 51### Stable Release 52 53**7 weeks** after the branch point a new major version is released. The 54stable rollout is staged over time so that any issues can be detected early and 55addressed before they reach all users. Each Chrome platform has a different 56stable rollout plan and the schedule below can vary based on circumstances: 57 58* **Desktop**: Desktop consists of three main platforms, Windows, Mac, and 59Linux. Linux is ramped up to 100% immediately. Mac and Windows follow a 60staged rollout as follows: 61 * 5% deployment ->15% deployment ->50% deployment ->100% deployment. 62* **Android**: Android releases both Chrome and WebView with each release, and 63follows a pattern similar to: 64 * 1% deployment -> 5% deployment -> 10% deployment -> 50% deployment 65 -> 100% deployment. 66* **iOS**: iOS follows a phased release with no control over the following 67rollout percentage schedule: 68 * Day 1: 1% -> Day 2: 2% -> Day 3: 5% -> Day 4: 10% -> Day 5: 20% 69 -> Day 6: 50% -> Day 7: 100%. 70 71### Stable Refresh 72 73A stable refresh is defined as a release of a new Chrome build outside of the 74normal release schedule to fix critical bugs detected during the stable rollout. 75Except for extremely critical issues (e.g. security or privacy escalations), 76a Chrome stable refresh should not be pushed more than **2 weeks** after the 77initial build has been released to the public. In this case, we should consider 78punting any detected production issues to the next release. 79 80## More Info 81 82For more information, see these [guidelines for considering branch dates in project planning](../release_branch_guidance.md). 83
