How should plugin developers manage the migration to Flutter 3?

[ryanheise]

Flutter 3 introduces nullability changes to WidgetsBinding but plugins (including the first class plugins) have been using a version spec like this:

  sdk: ">=2.14.0 <3.0.0"
  flutter: ">=2.10.0"

The first issue is that I assume that Flutter 3 could in theory introduce breaking changes because it is a major version bump, yet the constraint >=2.10.0 doesn't guard against that.

But the second issue is that if a plugin migrates to Flutter 3 and uses the new nullability on WidgetsBinding, and sets a minimum Flutter version constraint to ">=3.0.0", then we are likely to have a similar situation to the Flutter 2 migration with many plugins lagging behind in the migration process blocking the adoption of Flutter 3.

What is the official advice on how to manage the Flutter 3 migration process?

The video_player plugin has a workaround in the form of:

T? _ambiguate<T>(T? value) => value;
...
_ambiguate(WidgetsBinding.instance)!

This technique could be helpful to include in the official migration advice.

[darshankawar]

Thanks for the report. Keeping it open for further insights from the team.

[goderbauer]

/cc @Hixie @stuartmorgan @christopherfujino

[goderbauer]

Related: #103561

[Hixie]

in flutter/website#7128 i add the _ambiguate suggestion to the release notes

[stuartmorgan]

But the second issue is that if a plugin migrates to Flutter 3 and uses the new nullability on WidgetsBinding, and sets a minimum Flutter version constraint to ">=3.0.0", then we are likely to have a similar situation to the Flutter 2 migration with many plugins lagging behind in the migration process blocking the adoption of Flutter 3.

People updating Flutter constraints to 3.0.0 wouldn't create the kind of problem the NNBD transition did, because updating the minimum Flutter version isn't a breaking change. Someone can adopt Flutter 3 for their app with an arbitrary combination of plugins that require 3.0, plugins that support older versions with something like ambiguate, and plugins that haven't been updated at all (and thus have warnings).

The Flutter 2/NNBD transition was a very unusual case caused by needing to ripple breaking version changes, which must be explicitly adopted and which conflict with un-migrated dependency trees, across essentially the entire ecosystem.

[ryanheise]

I think there is still an issue here. Because plugins do not include a maximum constraint on Flutter, that is implicitly saying that a plugin will continue to work on every future version of Flutter. This change to nullability in Flutter 3 fortunately only generates compiler warnings and not errors, but in theory, new Flutter versions could introduce API changes that also generate compiler errors. So why aren't plugins placing a maximum constraint on the Flutter version?

Reading the Flutter compatibility policy, there is also no indication that semantic versioning is being used to indicate breaking changes, which would make it very difficult to actually know what the correct maximum constraint should be.

If these constraints were all made explicit, the migration advice might suggest not only using _ambiguate, but also reflecting the corresponding Flutter versions that this supports.

[Hixie]

So why aren't plugins placing a maximum constraint on the Flutter version?

Because as you say, we give:

no indication that semantic versioning is being used to indicate breaking changes, which would make it very difficult to actually know what the correct maximum constraint should be.

In fact, we don't use semantic versioning for Flutter at all, because every release has breaking changes, so it would be somewhat pointless.

There's really no way to know what the maximum version should be.

[christopherfujino]

Related #95472 (TL;DR there is currently no way to constrain a maximum Flutter version, by design)

[stuartmorgan]

See also #96282 which highlights some of the reasons semver wouldn't work well for Flutter.

(Also note that if we did use semver, and package authors did set constraints, the effect would be that every single Flutter package would stop working every time Flutter were updated, and they would all have to be updated by their authors every time. And running pretty much anything on master would be impossible. It would be a lot worse than the current situation.)

[stuartmorgan]

I'm going to close this; flutter/website#7128 documented the specific issue requested the issue was about (how libraries can handle this specific change in Flutter 3.0). And as discussed above, the secondary question of maximum Flutter versions is intentionally the way it is; any further discussion there would belong in #96282.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.