2070775d63
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}
23 lines
1.3 KiB
Markdown
23 lines
1.3 KiB
Markdown
# 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.
|
|
|