Dart 3.12 の dev タグは速く動いている: Flutter 3.x 開発者として読み方 (と何をするか)

Dart SDK のリリースフィードはここ 48 時間異常に活発で、複数の Dart 3.12 dev タグが立て続けに出ています (例: 3.12.0-12.0.dev)。Flutter 3.x の stable を出荷しているとしても、これらのタグは重要です。来たる言語、アナライザー、VM の変更の早期シグナルだからです。

ソース: Dart SDK 3.12.0-12.0.dev

dev タグは「リリース」ではないが、互換性のプレビューではある

Flutter stable を使っているなら、ツールチェーンを無造作に dev SDK へアップグレードすべきではありません。しかし dev タグを戦略的に使うことはできます。

• アナライザーの破壊を早期に捕捉: lint やアナライザーエラーが、自分の問題になる前に表面化します。
• ビルドツーリングを検証: コードジェネレーター、build runner、CI スクリプトが先に壊れがちです。
• マイグレーションコストの見積もり: 依存しているパッケージが脆いなら、リリース当日ではなく今のうちに分かります。

dev タグは互換性プレビューチャネルだと考えてください。

推測せずにバージョン文字列を読む

3.12.0-12.0.dev という形式は、「3.12.0 プレリリース、dev ビルド番号 12」と捉えれば自然になります。番号そのものから機能を推測する必要はありません。テストの際に既知のツールチェーンを固定するのに使うのです。

実践として。

• 短命な調査ブランチに dev タグを 1 つ選ぶ。
• 結果を再現できるよう 明示的にピン留めする。
• 現実的なワークロードを実行する: flutter test、リリースビルド、コード生成を使うなら少なくとも 1 回の build_runner 実行。

CI で特定の Dart SDK をピン留めする (誰の一日も壊さずに)

ここに、ピン留めした SDK をセットアップして通常のチェックを走らせる最小限の GitHub Actions の例を示します。これは意図的にメインビルドから分離してあり、失敗を「世界停止」ではなく「シグナル」として扱えます。

name: dart-dev-signal
on:
  schedule:
    - cron: "0 6 * * *" # daily
  workflow_dispatch:

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Pin a specific dev tag so failures are reproducible.
      # Follow Dart SDK release assets/docs for the right install method for your runner.
      - name: Install Dart SDK dev
        run: |
          echo "Pin Dart 3.12.0-12.0.dev here"
          dart --version

      - name: Analyze + test
        run: |
          dart pub get
          dart analyze
          dart test

重要な振る舞いはインストーラのスニペットではなく、ポリシーです。このジョブはカナリアです。

失敗をどう扱うか

dev チャネルがビルドを壊したら、失敗には単一の質問に答えてもらいましょう。「これは自分たちのコードか、依存先か」です。

迅速なトリアージのチェックリスト。

• アナライザーエラーが変わったら: コードベースの新しい lint や型付けの厳格化をチェック。
• build_runner が失敗したら: まずジェネレーターをピン留めして更新し、再実行。
• 依存先が失敗したら: 「最新 dev」ではなく正確な dev タグを添えて上流に issue を立てる。

報酬は地味ですが本物です。Flutter が最終的に新しい Dart ツールチェーンを取り込んだとき、マイグレーションは消火活動ではなく小さな PR になります。

リソース: Dart SDK releases