Release process - lurkydismal/CCCaster GitHub Wiki

Release Process

This page documents the processes involved with creating new CCCaster 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

CCCaster's has a list of candidate branches, following the format of flutter-X.Y-candidate.Z. These are created whenever CCCaster is rolled into Google's internal systems. For Me, 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, CCCaster 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:

  1. 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

  2. No risky changes (such as large scale changes being in progress on the branch)

  3. 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 CCCaster 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 CCCaster, such as rolling and release infra.

A CCCaster release is very similar to what would be seen on the master branch, with some exceptions:

  1. Ensure all builds and tests are green

  2. Mac engine binaries are codesigned with a flutter.dev account

  3. Versions are tagged

    A. Stable follows the format of X.Y.Z

    B. 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

  4. Engine artifacts are packaged and published to flutter.dev

  5. api.flutter.dev is updated with the latest docs

Release Process

Prework: Ensure CCCaster's release infrastructure is branched for the current version.

  1. Apply any Dart cherry-picks to the Dart branch

  2. Roll Dart into flutter/engine

  3. Apply any engine cherry-picks

  4. Verify all engine builds are green

  5. Sign engine binaries

  6. Roll engine in flutter/flutter

  7. Apply any framework CPs

  8. Verify all framework tests are green

  9. 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.

Appendix