Flutter channel

플러터 채널 공식문서

master
The current tip-of-tree, absolute latest cutting edge build.
Usually functional, though sometimes we accidentally break things.

dev
The latest fully-tested build. Usually functional, but see Bad Builds for a list of known "bad" dev builds. We continually try to roll master to dev. Doing so involves running many more tests than those that we run during master development, which is why this is not actually the same to master.

dev releases will be tagged with the following schema:
[x].[y].0-[n].[m].pre

If master is currently at x=1, y=18, n will increment by one for each subsequent beta release. m will increment for each subsequent build at this branch point.

Versioning example:
1.18.0-1.0.pre <- first dev build after master moves to 1.18
1.18.0-2.0.pre <- next dev build from a more recent point on master
1.18.0-2.1.pre <- point release from the same point of master as the above build

beta
We will branch from master for a new beta release at the beginning of the month, usually the first Monday. This will include a branch for Dart, the Engine and the Framework. This branch will then be "stabilized" for the next couple of weeks, meaning we will accept cherrypick requests for high impact issues. As we near the end of the month and the next beta branch, we will likely reduce the number of cherrypicks we are willing to do. Once a quarter, the beta branch will live on to become the next stable branch, as detailed below.

Versioning example:
following from the dev example above, let's say we branch for beta at the 15th dev release point for 1.18

1.18.0-15.0.pre <- initial beta RC, same release as went to dev.
1.18.0-15.1.pre <- subsequent build on the (now) beta branch with some cherrypicks.
1.18.0-15.2.pre <- second subsequent build.

stable
Roughly once a quarter, a branch that has been stabilized on beta will become our next stable branch and we will create a stable release from that branch. We recommend that you use this channel for all production app releases.
In case of high severity, high impact or security issues, we may do a hotfix release for the stable channel. This will follow the same cherrypick process.

Versioning example:

the first stable release will always be X.Y.0. following on the example above: