Previously we had a lot of documentation bundled in the `workflows.md` file, which wasn't necessarily obvious to new users. The getting the code documentation now lives in a dedicated file `get_the_code.md`, which is also directly linked from the toplevel `README.md`, since that's what developers are looking first. It also rearranges the rest of the project documentation a bit to move the most important things to the top, add [TOC]s everywhere and streamlines the documentation around (3rd party) dependencies, as well as updating the documentation on testing. Bug: none Change-Id: I7b5d9121c7f1137eeff7a4ff159816908ef10705 Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4931037 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
2.1 KiB
Release Management
Merges and Cherry-Picks
The documentation on cherry-picks and merges (including backmerges and backports) can be found in contributing_changes.md.
Versioning
There is no explicit versioning being done. At the time of writing no compelling use case was found that would require version numbers. Commits are identified by their commit hash, which should suffice for the projected future.
What happens when Chromium cuts a new Canary branch
For each Chromium release branch, we create a mirror branch with the same name on our repo. Rough outline:
- Chromium cuts a branch e.g. 3879
- Bots create Chromium/3879 branch on the DevTools frontend repo
- The end
Handling of Beta/Stable branches
Generally speaking, beta/stable branches are the same as Canary branches. There is a special waterfall though, that runs tests on the beta/stable branches.
When Chromium updates to a new major version we need to update the branch number in infra/config branch of devtools-frontend. Specifically, in file buckets/ci.start, promote the existing beta branch to stable section and modify beta section with the corresponding branch number for the new Chromium milestone.
generate_ci_configs(
configurations = [
...
config_section(
name="beta",
branch='refs/heads/chromium/4044',
),
config_section(
name="stable",
branch='refs/heads/chromium/3987',
),
...
After editing the above mentioned file run lucicfg generate main.star to have the change propagated to the cfg files.
Example: CL
Rolling/Integrating into Chromium
The Skia autoroller is used. The DevTools-Frontend auto-roller state can be seen and controlled here.