Update release cycle documentation to reflect 5 weeks between branch and stable release
Change-Id: Ieeab53e121d8ab75d8f108e39ad6b950551bf0e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4403612 Reviewed-by: Krishna Govind <govind@chromium.org> Commit-Queue: Harry Souders <harrysouders@google.com> Cr-Commit-Position: refs/heads/main@{#1126918}
This commit is contained in:

committed by
Chromium LUCI CQ

parent
1bc20e7b6f
commit
d65c2aef41
docs/process
Binary file not shown.
Before ![]() (image error) Size: 19 KiB After ![]() (image error) Size: 19 KiB ![]() ![]() |
Binary file not shown.
Before ![]() (image error) Size: 21 KiB After ![]() (image error) Size: 20 KiB ![]() ![]() |
Binary file not shown.
Before ![]() (image error) Size: 33 KiB After ![]() (image error) Size: 34 KiB ![]() ![]() |
@ -7,7 +7,7 @@
|
||||
Chrome ships a new milestone (major version) to the stable channel every four
|
||||
weeks. The new milestone is developed on main for four weeks (beginning on
|
||||
branch point for the previous milestone) before the milestone's branch is cut,
|
||||
which is then stabilized for six weeks before being shipped to stable. Once
|
||||
which is then stabilized for five weeks before being shipped to stable. Once
|
||||
a milestone reaches stable, biweekly updates (called refreshes) are shipped to
|
||||
the stable to deploy security fixes and keep Chrome's
|
||||
[patch gap](https://groups.google.com/a/chromium.org/g/security-dev/c/fbiuFbW07vI)
|
||||
@ -66,7 +66,7 @@ milestone.
|
||||
|
||||
The branch generated by the daily canary created at branch point is
|
||||
designated as the milestone branch, which is then stabilized over the following
|
||||
six weeks. All strings should be landed by branch point, and all beta blocking
|
||||
five weeks. All strings should be landed by branch point, and all beta blocking
|
||||
bugs should be addressed as well.
|
||||
|
||||
Please consider [these guidelines](../release_branch_guidance.md) when landing
|
||||
@ -74,7 +74,7 @@ code around branch point.
|
||||
|
||||
### Beta Promotion
|
||||
|
||||
After two weeks of stabilization, the new milestone is shipped to the beta
|
||||
After one week of stabilization, the new milestone is shipped to the beta
|
||||
channel for the first time. A new build is shipped to beta each following
|
||||
week for three additional weeks so that the release spends four weeks total in
|
||||
the beta channel.
|
||||
@ -95,9 +95,9 @@ early issues that arise can be addressed before they reach all users. The new
|
||||
release generally reaches all users within one to two weeks unless major issues
|
||||
arise that cannot be addressed quickly.
|
||||
|
||||
To get better statistical data for staged rollouts, each rollout will consist of
|
||||
two separate builds which are identical, except for the build number. There is no
|
||||
harm in being on the lower build number, and all users are expected to be
|
||||
To get better statistical data for staged rollouts, each rollout will consist of
|
||||
two separate builds which are identical, except for the build number. There is no
|
||||
harm in being on the lower build number, and all users are expected to be
|
||||
automatically updated to the higher build number as part of the rollout process.
|
||||
|
||||
### Stable Refresh
|
||||
|
Reference in New Issue
Block a user