46ef0dea2f
3 notable places I did not migrate. 1. engine/src/flutter/docs/Engine-disk-footprint.md treemaps and what hash is used for what upload. 1. engine/src/flutter/lib/gpu/pubspec.yaml, I didnt want this pr to update code that could need to be reverted and I didnt know what to do to test that publishing would not break or cause a downstream breakage. 1. engine/src/flutter/build/zip_bundle.gni I wasnt sure how to test my changes. Reviewers: Please let me know if you want a different link or if you would prefer something unmodified. Commits: - **Replace triage links with equivalents, change pull request to generic flutter/flutter, replace code search link with equivalent** - **Change link from flutter/engine to engine folder, modify link text to team** - **replace engine repo link with engine folder, replace text repo with folder** - **replace engine specific security info with flutter generic** - **replace engine roller comment with a skia roller equivalent** - **link to same file in new location** - **Remove comment that some code lives in flutter/flutter and some in flutter/engine** - **Say to bump dart in flutter/flutter without mentioning engine** - **Replace documentation with new locations** - **replace code printed comments with new locations** Partially addresses https://github.com/flutter/flutter/issues/167478 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing.
4.2 KiB
Release Process
This page documents the processes involved with creating new Flutter releases. If you're interested in learning more about why certain branch points are chosen, or how releases are built, continue reading. If you're looking for the current release info, see the appendix at the bottom.
Creating new branches
Flutter's has a list of candidate branches, following the format of flutter-X.Y-candidate.Z. These are created whenever Flutter is rolled into Google's internal systems. For Googlers, see go/flutter-life-of-a-pr. Generally, these branches are created every few days, and stabilized so they don't break Google tests (such as reverting commits with breakages).
Selecting a candidate branch
At the start of every month, Flutter aims to ship a new beta to users. We prefer picking the most recent candidate branches for betas, but there are some things we check for:
-
Dart version is ok to ship.
A. Verify the version has been rolled and verified in Google's internal codebase
B. Dart team is ok with shipping this release
-
No risky changes (such as large scale changes being in progress on the branch)
-
Timing makes sense A. For betas that will be promoted to stable, announcements are sent to contributors about the cutoff date. A beta may be held to ensure the cut off date has had a branch point
Conducting releases
Conductor is a release tool written in Dart to drive Flutter releases. It's the source of truth for what's needed to ship a release. Generally, it can promote candidate branches to betas, betas to stable, and hotfix releases. It handles the nuances of git, such as pushes, cherrypicks, and tagging, and the complexities of Flutter, such as rolling and release infra.
A Flutter release is very similar to what would be seen on the master branch, with some exceptions:
-
Ensure all builds and tests are green
-
Mac engine binaries are codesigned with a flutter.dev account
-
A. Stable follows the format of
X.Y.ZB. Beta follows the format of
X.Y.Z-M.N.pre, where M=number of candidate branches since last beta, and N=number of hotfixes since branching -
Engine artifacts are packaged and published to flutter.dev
-
api.flutter.dev is updated with the latest docs
Release Process
Prework: Ensure Flutter's release infrastructure is branched for the current version.
-
Apply any Dart cherry-picks to the Dart branch
-
Bump Dart version
-
Apply any engine cherry-picks
-
Verify all engine builds are green
-
Sign engine binaries
-
Roll engine in flutter/flutter
-
Apply any framework CPs
-
Verify all framework tests are green
-
Push release to the beta or stable branch, and tag it
A. This then triggers our packaging builders to update the website
Hot-fixing releases
Cherry-pick requests are triaged, and determined if they need a hot-fix. Features are not permitted to be hot-fixed into a release. Approved CP requests are then included in the weekly hot-fix.
Hot-fixes follow the same release process.
FAQ
What is packaging?
Packaging is the process of creating an offline zip that includes everything needed to run flutter. Generally, it's a git checkout with flutter precache run.
What version strategy does Flutter use?
Flutter does not use semver. Generally, our increments happen based on time intervals. Z is incremented whenever we ship a weekly hotfix.
Why do releases require a force push?
Since stable and beta are branches, new Y releases require a force push. This is due to us not merging the release branch back into main.