skip to content

What are the Dart SDK's stable, beta and dev release channels, and what does dart info report when you file a tooling bug?

level: juniorimportance: nice to knowfreq 15%

answer

  1. stable roughly every three months
  2. beta monthly, dev twice a week
  3. suffix .beta or .dev in the version
  4. only the latest stable is supported
  5. file paths removed by default

basics

~20 s

Stable ships about every three months for production; beta about monthly as a pre-release; dev about twice a week for recent fixes and experiments. dart info prints the SDK version and channel, OS, locale, running Dart processes and, in a package, project details.

solid answer

~40 s

Dart publishes to three channels. **Stable** (`x.y.z`, for example `3.13.4`) ships about every three months and is the only one for production; the Dart team supports only the latest stable release, with patch releases for critical and security fixes. **Beta** (`x.y.z-a.b.beta`) ships about monthly for testing compatibility with the next stable. **Dev** (`x.y.z-a.b.dev`) ships about twice a week for trying recent fixes and experimental features; some experiment flags are only accepted on certain channels. `dart --version` shows the version and channel. `dart info` prints a bug-report-ready summary: the Dart version and channel, the OS and locale, running Dart processes with memory and CPU, and - inside a package - the SDK constraint and dependencies. It removes file paths by default; `--no-remove-file-paths` keeps them. In a Flutter install, `dart` is the SDK bundled with Flutter.

go deeper

for a junior

Recall the three channels, their rough cadence and that production uses stable.

for a middle

Explain the version-string formats, the latest-stable-only support policy and what dart info reports.

for a senior

Keep teams on a supported stable, trial the next release on beta in CI, and file tooling bugs with reviewed dart info output.

for a principal

Set an SDK upgrade cadence that keeps every product within the supported release without disrupting delivery.

## Three channels The Dart SDK is published on three **release channels**, each with its own cadence, version format and purpose: | Channel | Cadence (approx.) | Version format | Use it for | |---|---|---|---| | stable | every three months | `x.y.z` | building and deploying production apps | | beta | once a month | `x.y.z-a.b.beta` | testing compatibility with future stable versions | | dev | twice a week | `x.y.z-a.b.dev` | testing recent fixes and experimental features | In the pre-release formats, `a` and `b` are the pre-release version and its patch. You can therefore tell the channel from the version string alone: `3.13.4` is stable, something ending in `.beta` is beta. ## The support policy The Dart team supports **only the latest stable release**. When a new minor or major version ships, the previous one stops receiving fixes. Critical bugs and security issues are fixed through **patch releases** of the current version - the `z` in `x.y.z`. The practical consequence: staying a few releases behind means you do not receive security patches, and a bug fix you need may only exist in a newer minor version. ## Channels and experiments Language and tooling features under development sit behind **experiment flags**. The `dart` tool checks each requested experiment against the channel it is running on and rejects one that is only available on other channels, naming the channels where it is. That is one reason experimental work happens on dev or beta SDKs. ## Dart inside Flutter A Flutter installation bundles its own Dart SDK, so the `dart` command inside it reports whatever Dart version that Flutter release carries - Flutter 3.47 carries Dart 3.13. You change the Dart version there by changing the Flutter version, not by installing a separate Dart channel. ## dart info for bug reports `dart info` gathers the facts a tooling bug report needs: - **General info** - the Dart version string (including channel and build date), the operating system and its version, and the locale. - **Process info** - running Dart processes such as the analysis server, with memory, CPU and elapsed time. This is what shows a runaway analysis server. - **Project info** - when run in a directory with a `pubspec.yaml`: the SDK constraint and the dependencies. By default it **removes file paths** from the output, since paths can leak user names or project names; `--no-remove-file-paths` includes them. The command itself prints a reminder to review the output before posting it publicly. ## A reporting routine 1. Reproduce the problem on the latest stable if you can - older versions are unsupported. 2. Run `dart info` in the affected package. 3. Review the output for anything private, then attach it to the issue. ## Common mistakes - Shipping production code built on a beta or dev SDK. - Reporting a bug against an old minor version and expecting a patch for it. - Pasting `dart info` output with `--no-remove-file-paths` into a public tracker without reviewing it.

  • How can you tell from 3.14.0-120.2.beta which channel an SDK came from?
    Stable versions are plain `x.y.z`. Pre-release builds append `-a.b.beta` or `-a.b.dev`, so the `.beta` suffix marks the beta channel; `120` is the pre-release version and `2` its patch.
  • Why does dart info remove file paths unless told otherwise?
    The output is meant to be pasted into public bug reports, and absolute paths can reveal user names, company names or project structure. `--no-remove-file-paths` includes them when a maintainer needs them.

saying these in an interview costs you the question

  • Thinks every past stable release still receives security patches
  • Believes beta builds are fine for production apps
  • Assumes the dev channel means the development build of stable
  • Thinks dart info uploads a report automatically
  • Believes Flutter's dart can be switched to another channel independently