Die Dev-Tags von Dart 3.12 kommen schnell: Wie Sie sie als Flutter 3.x-Entwickler lesen (und was zu tun ist)

Der Release-Feed des Dart-SDK war in den letzten 48 Stunden ungewöhnlich aktiv, mit mehreren Dart 3.12 dev-Tags hintereinander (zum Beispiel 3.12.0-12.0.dev). Selbst wenn Sie Flutter 3.x stable ausliefern, sind diese Tags wichtig, weil sie ein frühes Signal für anstehende Änderungen an Sprache, Analyzer und VM sind.

Quelle: Dart SDK 3.12.0-12.0.dev

Ein Dev-Tag ist kein “Release”, aber eine Kompatibilitätsvorschau

Wenn Sie auf Flutter stable sind, sollten Sie Ihre Toolchain nicht wahllos auf ein Dev-SDK aktualisieren. Aber Sie können Dev-Tags strategisch nutzen:

• Analyzer-Brüche früh erkennen: Lints und Analyzer-Fehler kommen ans Licht, bevor sie Ihr Problem werden.
• Build-Tooling validieren: Code-Generatoren, Build Runner und CI-Skripte fallen oft zuerst aus.
• Migrationsaufwand abschätzen: Wenn ein Paket, von dem Sie abhängen, fragil ist, erfahren Sie das jetzt, nicht am Release-Tag.

Betrachten Sie Dev-Tags als Kompatibilitäts-Vorschau-Kanal.

Den Versionsstring ohne Raten lesen

Das Format 3.12.0-12.0.dev sieht seltsam aus, bis Sie es so lesen: “3.12.0 prerelease, Dev-Build Nummer 12”. Sie müssen aus der Zahl selbst keine Funktionen ableiten. Sie nutzen sie, um beim Testen eine bekannte Toolchain festzunageln.

In der Praxis:

• Wählen Sie ein Dev-Tag für einen kurzlebigen Untersuchungszweig.
• Pinnen Sie es explizit, damit Sie Ergebnisse reproduzieren können.
• Lassen Sie eine realistische Last laufen: flutter test, einen Release-Build und mindestens einen build_runner-Lauf, falls Sie Codegen nutzen.

Eine bestimmte Dart-SDK-Version in CI pinnen (ohne anderen den Tag zu zerstören)

Hier ein minimales GitHub-Actions-Beispiel, das ein gepinntes SDK einrichtet und die üblichen Prüfungen ausführt. Das ist absichtlich von Ihrem Hauptbuild getrennt, damit Sie Fehlschläge als “Signal”, nicht als “Stop the world” behandeln können.

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

Das wichtige Verhalten ist nicht das Installer-Snippet, es ist die Richtlinie: dieser Job ist ein Kanarienvogel.

Was Sie mit Fehlschlägen tun

Wenn der Dev-Kanal Ihren Build bricht, soll der Fehlschlag eine einzige Frage beantworten: “Ist es unser Code oder sind es unsere Abhängigkeiten?”

Schnelle Triage-Checkliste:

• Wenn sich Analyzer-Fehler änderten: prüfen Sie auf neue Lints oder strengere Typisierung in Ihrem Codebase.
• Wenn build_runner fehlschlägt: pinnen und aktualisieren Sie zuerst die Generatoren, dann erneut ausführen.
• Wenn eine Abhängigkeit fehlschlägt: öffnen Sie ein Upstream-Issue mit dem exakten Dev-Tag, nicht “latest dev”.

Die Belohnung ist langweilig, aber echt: Wenn Flutter schließlich die neuere Dart-Toolchain übernimmt, ist Ihre Migration ein kleiner PR statt einer Brandübung.

Ressource: Dart SDK releases