Add branch date guidance to documentation.
This is a set of guidelines that the Blink/Web Platform team leads came up with, based on experience and input from TPMs. R=amineer@chromium.org BUG= Change-Id: Iff53ce441ab46bd52ada5285ad94af57dce27b18 Reviewed-on: https://chromium-review.googlesource.com/693345 Reviewed-by: Alex Mineer <amineer@chromium.org> Commit-Queue: Dimitri Glazkov <dglazkov@chromium.org> Cr-Commit-Position: refs/heads/master@{#511203}
This commit is contained in:

committed by
Commit Bot

parent
017b79e68a
commit
2070775d63
@ -135,6 +135,9 @@ used when committed.
|
||||
features in Chromium
|
||||
* [Adding a new feature flag in chrome://flags](how_to_add_your_feature_flag.md) - Quick
|
||||
guide to add a new feature flag to experiment your feature.
|
||||
* [Guidelines for considering branch dates in project planning](release_branch_guidance.md) -
|
||||
What to do (and not to do) around branch dates when scheduling your project
|
||||
work.
|
||||
|
||||
### Testing
|
||||
* [Running and Debugging Layout Tests](testing/layout_tests.md)
|
||||
|
@ -45,7 +45,8 @@ 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.
|
||||
basis. For Chrome OS, the stable cut date may be different than the rest of
|
||||
Chrome.
|
||||
|
||||
### Stable Release
|
||||
|
||||
@ -75,3 +76,7 @@ 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.
|
||||
|
||||
## More Info
|
||||
|
||||
For more information, see these [guidelines for considering branch dates in project planning](../release_branch_guidance.md).
|
||||
|
22
docs/release_branch_guidance.md
Normal file
22
docs/release_branch_guidance.md
Normal file
@ -0,0 +1,22 @@
|
||||
# Guidelines for Considering Branch Date in Project Planning
|
||||
|
||||
* Avoid changes to persisted data (e.g. data serialization, database schemas,
|
||||
etc) just before branch due to the risk of reverts. If you modify data that
|
||||
will be synced, this change should be forward compatible for up to four
|
||||
milestones (as stable and canary are at times four milestones apart and it's
|
||||
easonable to assume that somebody runs stable on chromeos and canary on mac,
|
||||
both syncing to the same account).
|
||||
* Two weeks prior to the branch point, avoid committing big and risky changes
|
||||
or enabling non-trivial features.
|
||||
* Pay more attention to complexity and structure of CLs around branch points,
|
||||
in case fixes need to be merged back after branch is created. Break up a CL
|
||||
into smaller pieces to facilitate potential merges.
|
||||
* As the branch point gets closer, consider if there is data to gather (like
|
||||
adding use counters, or other histograms that we want) and prioritize that
|
||||
work. Metrics changes on branch don't meet the bar.
|
||||
* Prioritize stability and "bake time", as well as other ways to reduce the
|
||||
release risk in your timeline discussions.
|
||||
* Consider API adoption timelines: code may not be exercised until developers
|
||||
adopt API, so feature freeze and branch could have minimal impact on
|
||||
stability.
|
||||
|
Reference in New Issue
Block a user