A communityWhen an SDK switch and a dependency update happen together, a changed result has more than one possible cause. Record both inputs and separate the experiments.
Inventory the dependency inputs
Read the application’s pubspec.yaml, existing pubspec.lock and any dependency overrides. Dart supports hosted, Git, path and SDK dependencies. A local path or override can make a result depend on work that another developer does not have.
The lockfile records resolved package versions. It is not an identifier for the Flutter SDK itself. Keep the SDK repository and revision as separate fields. Preserve an application’s existing lockfile before a comparison, and investigate a resolution change instead of discarding it.
| Input | Question to answer |
|---|---|
| pubspec.yaml | Which dependencies and SDK constraints were requested? |
| pubspec.lock | Which package versions and sources were resolved? |
| Overrides | Was the normal resolution replaced locally? |
| Path/Git dependency | Can another developer access the same intended source? |
| SDK record | Which Flutter/Flock checkout actually ran? |
Split a mixed change
Start with a known baseline and preserve its dependency state. Evaluate the candidate SDK with the intended dependency inputs, noting any resolution change that the tool requires. If you also need a package upgrade, treat that as a second documented trial rather than folding it into the SDK conclusion.
Synthetic comparison log
A: Baseline SDK + original dependency state
B: Candidate SDK + same intended dependency state
C: Separate package-change trial, if required
For each run record:
SDK revision / package resolution / target / mode
Command and first relevant error
Original reproduction result
Any unsupported combination, explicitly markedExplain the result without over-attribution
Suppose a synthetic issue disappears after both a framework change and a package update. The result establishes that the new combination behaves differently. It does not yet show which change removed the failure. A controlled comparison can narrow that question.
If the old package constraints cannot work with the candidate, record the incompatibility. Do not claim to have tested an unchanged dependency set when resolution selected something else. Keep private paths and credentials out of a shared dependency report.
Read requested dependencies → Preserve the resolved state → Separate mixed changes → Attribute only observed results.
Primary sources
Continue with the next step
Resolve the next specific question
- Audit an SDK migration before applying broad fixes
Map baseline-to-candidate changes to applicable notices, previewed edits and target checks.
- Separate download failures from Flutter SDK failures
Identify repository, package or artifact retrieval failures before changing app code during an SDK trial.