Flutter SDK version drift across team machines despite pubspec.lock

Answers

1. Recommended approach without external version managers: Pin the Flutter SDK by checking out a specific Git commit hash (or release tag) in the SDK directory and enforce it with a tight environment constraint in pubspec.yaml.

2. CI pipeline guarantee: In your CI configuration, request the exact same Flutter version (or commit) rather than using a moving alias like stable. For example, in GitHub Actions with subosito/flutter-action set flutter-version: '3.19.0' or the corresponding commit hash.

3. Official version‑locking manifest: The Flutter team has not announced plans for a dedicated lockfile; the environment block in pubspec.yaml is the official way to signal SDK compatibility, leaving version enforcement to the user or CI.

Confirmed facts

• pubspec.lock only records Dart package versions, not the Flutter SDK itself.
• The environment constraint (e.g., sdk: '>=3.3.0 <3.4.0') causes the build to fail if the installed SDK is outside the range, but does not install a specific version.
• Flutter SDK source is a Git repository; checking out a particular commit (e.g., git checkout 123abc4) yields an exact, reproducible SDK.

Likely explanation for drift

Developers often run flutter upgrade without a specific target, which pulls the latest stable channel. CI jobs that use flutter-version: 'stable' resolve to whatever is latest at runtime, leading to mismatched SDKs across machines.

Steps to synchronize (no external manager)

1. Choose a reference version, e.g., Flutter 3.19.0 or its Git commit hash abcdef1234.
2. In pubspec.yaml, set a narrow environment constraint that matches that version:

   environment:
     sdk: '>=3.3.0 <3.4.0'

3. Each team member runs (adjust path to their Flutter SDK clone):

   cd /path/to/flutter
     git checkout abcdef1234
     flutter precache

4. Verify with flutter --version; the output should show the same commit hash.
5. In CI, configure the setup step to request the exact version/commit, e.g.:

   - uses: subosito/flutter-action@v2
     with:
       flutter-version: '3.19.0'

Verification

On every machine and in CI, run:

flutter --version

Compare the Flutter version and the Git commit hash. If they match, the SDK is aligned.

Diagnostic detail needed: Are you currently using a shared internal mirror of the Flutter SDK, or does each developer download the SDK independently from the official channels? This affects whether the git checkout step must point to a local mirror.