0

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:
Harry Souders
2023-04-05 23:49:46 +00:00
committed by Chromium LUCI CQ
parent 1bc20e7b6f
commit d65c2aef41
4 changed files with 6 additions and 6 deletions

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