forked from chromium/chromium
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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}
- Loading branch information
Showing
3 changed files
with
31 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. | ||
|