Los tags dev de Dart 3.12 se mueven rápido: cómo leerlos (y qué hacer) como desarrollador de Flutter 3.x

El feed de releases del SDK de Dart ha estado inusualmente activo en las últimas 48 horas, con múltiples tags Dart 3.12 dev aterrizando uno tras otro (por ejemplo 3.12.0-12.0.dev). Incluso si envías Flutter 3.x estable, estos tags importan porque son una señal temprana de los próximos cambios de lenguaje, analizador y VM.

Fuente: Dart SDK 3.12.0-12.0.dev

Un tag dev no es un “release”, pero sí una vista previa de compatibilidad

Si estás en Flutter estable, no deberías actualizar al azar tu toolchain a un SDK dev. Pero puedes usar los tags dev de forma estratégica:

• Atrapar roturas del analizador temprano: lints y errores del analizador salen a la luz antes de que se conviertan en tu problema.
• Validar herramientas de compilación: los generadores de código, build runners y scripts de CI suelen fallar primero.
• Evaluar el costo de migración: si un paquete del que dependes es frágil, te enteras ahora, no el día del release.

Piensa en los tags dev como un canal de vista previa de compatibilidad.

Leer la cadena de versión sin adivinar

El formato 3.12.0-12.0.dev parece raro hasta que lo tratas como: “3.12.0 prerelease, build dev número 12”. No necesitas inferir características del número en sí. Lo usas para fijar un toolchain conocido al probar.

En la práctica:

• Elige un tag dev para una rama de investigación de corta vida.
• Fíjalo explícitamente para poder reproducir resultados.
• Ejecuta una carga de trabajo realista: flutter test, una compilación de release y al menos una corrida de build_runner si usas codegen.

Fijar un SDK específico de Dart en CI (sin romperle el día a todo el mundo)

Aquí hay un ejemplo mínimo de GitHub Actions que configura un SDK fijado y ejecuta las verificaciones habituales. Esto está intencionalmente separado de tu compilación principal, así puedes tratar los fallos como “señal”, no como “parar el mundo”.

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

El comportamiento importante no es el snippet del instalador, es la política: este job es un canario.

Qué hacer con los fallos

Cuando el canal dev rompe tu build, quieres que el fallo responda a una sola pregunta: “¿es nuestro código, o son nuestras dependencias?”

Lista rápida de triaje:

• Si los errores del analizador cambiaron: revisa nuevos lints o tipado más estricto en tu código.
• Si build_runner falla: fija y actualiza los generadores primero, luego vuelve a ejecutar.
• Si una dependencia falla: abre una issue upstream con el tag dev exacto, no “último dev”.

La recompensa es aburrida pero real: cuando Flutter finalmente adopte el toolchain de Dart más nuevo, tu migración será un PR pequeño en lugar de una alarma de incendios.

Recurso: Dart SDK releases