Today, Flutter releases are triggered by a push to the release branch. From there, LUCI git pollers will pick up the new commits, and trigger packaging builds (one per host platform per architecture). At the end of each build, they are zipped, uploaded to cloud storage, and a manifest JSON file for the website is updated.

Problems with current process

1. If one of the packaging builds fail but others succeed (as happened here, we are in a strange state that is difficult to recover from.
2. There is latency between when the different platform archives are available on the website.
3. There is latency between when a release is pushed to the branch and when it is available on the website.
4. The release archive is not tested before it is publicly available (although the code has already been tested on the candidate branch).
5. Build triggering has to be timed approximately 1 hour before the intended release.

We should have a system where packaging archives are built but not publicly available, and then, upon all green builds, the release can be pushed to release branch which triggers a quick simple CI job that merely updates the website manifest.

Blockers to atomic releases

The Flutter tool assumes a release channel is a git branch (e.g. the source of truth for the stable channel is the upstream stable branch). It reports the current branch as the name of the local branch it has checked out, and it subscribes to upgrades by checking if the upstream remote branch has newer commits. To allow a release package to be created before it is publicly available to existing customers, either:

1. an SDK package would have to be created with a git repo whose release branch is ahead of the upstream repository yet still tracking it; or
2. the Flutter tool would have to be refactored to not rely on git branches for identifying the current release and for subscribing to upgrades.

Solution 1 would be messing with git history in a way that would be difficult to reason about and difficult to test, and Solution 2 would be a significant amount of work and need to be scoped with a design doc (especially how to subscribe to upgrades).