Challenge with Flutter 3.7 breaking none nullable .of changes

[rydmike]

Flutter 3.7 .of breaking changes

Flutter 3.7 added a large amount of breaking changes by making many nullable static Nnnn.of(context) functions non-nullable and introducing Nnnn.maybeOf(context) replacements.

This is similar to the big breaking change done in Flutter 2.0.0 described here https://docs.flutter.dev/release/breaking-changes/eliminating-nullok-parameters.

The change is understandable, both for consistence and efficiency of the non nullable variant. Apparently many where forgotten in the in Flutter 2.0.0 migration and new ones using the old style have even even been added after it.

These changes were not mentioned as planned and upcoming for next (this 3.7) release. However some of them were indeed listed as upcoming in a future release via https://docs.flutter.dev/release/breaking-changes/supplemental-maybeOf-migration.

This PR #114120 contains many of the commits that seem to match some of the above listed cases. Some others are not mentioned, like e.g. Overlay.of that has an earlier PR here #110811.

For applications the change is not a big issue. As long as there is a dart fix for all of them, the migration can be pretty smooth and quick. Additionally most of the impacted APIs are reasonably rare.

However, for packages that may prefer to support at least one major release backwards compatibility, these breaking changes are more troublesome. Converting a broken previously nullable .of to a nullable .maybeOf breaks backwards compatibility with all previous Flutter versions and requires a version constraint of min Flutter 3.7.0. Likewise keeping the none nullable .of results in a analyzer warning, package pub score reduction and most importantly a potentially troublesome use-case, if the nullable version was actually needed.

In the PR a potential soft approach was mentioned here #114120 (review) by @goderbauer.

I mentioned the same thought in a tweet here and likewise in the PR comment after discovering this here.

The staged softer approach would imo have been more considerate, by first adding the nullable maybeOf to Flutter 3.7, while still keeping the .of methods nullable as well. Then later switching the .of methods to none nullable, e.g. 4.0.0 could have been a nice future release for that. Would have been a logical point to introduce the breaking changes, just as 2.0.0 was for the bulk of the previous ones. Would have given time to migrate packages to .maybeOf over at least one stable overlap.

Repeat of Flutter 2.0.0 migration maybeOf package challenges?

The previous major .maybeOf breaking changes in Flutter 2.0.0 saw a lot of issues and challenges in packages due to this. Particularly with transitive dependencies not using the right version with maybeOf, and updates to packages simply just lagging behind a long time, blocking moving on to latest Flutter stable release. I am concerned we might face a similar situation again. Maybe I worry too much.

Options?

@gspencergoog and @goderbauer, I am aware that the ship has probably sailed on this topic and we will all just have to bite the hard break bullet. Unless of course the impacted .of:s are reverted to be nullable and the nullable .maybeOf kept. Then the staged approach would effectively be introduced.

I opened this as an issue to discuss and see what our options are, if any, based on suggestion by @timsneath's tweet comment here.

[goderbauer]

I understand that this has caused some issues for package authors. Apologies for that. We could have done a more staged roll-out, as was suggested in the PR and I will make a mental note that we consider this more strongly for future changes like this... Unfortunately, for this particular change, this ship has sailed now, though. I don't think there's anything we can do to rescue the situation.

Two suggestions though:

1. I would advice testing packages/apps that are sensitive to these kind of changes with the beta channel. That way, potential problematic changes can be detected earlier and if we receive feedback like this before we cut the next stable we may still be able to act on it.

2. For open-source packages, I also recommend donating any tests to https://github.com/flutter/tests. That broadens our test coverage and if the change would have broken a test there, it would have been a stronger signal for us to do a more careful rollout.

Again, apologies for the churn. Since there is likely nothing else we can do about this now, I am going to close the issue.

[rydmike]

Hi @goderbauer, thanks for your prompt reply and insights.

Personally I don't think it is a very big problem. As a package author, I can easily fix it and just set the version constraint to 3.7.0 and say, sorry no backwards compatibility beyond Flutter 3.7.0 anymore, Flutter SDK changes broke that.

However, based on the experience with the previous change of this type, with 2.0.0 there was a lot of complications for many devs with direct and transitive package deps where maybeOf migration was done for some packages and for others not.

This resulted in a situation where there was no resolvable constraints even with overrides, that would compile for all used packages in apps. Only solution was temporary cloning of such pub package repos, fixing the issue yourself, submitting a PR and hope for an eventual merge, and while waiting, using those packages from your GitHub clone to be able to build. Had two cases that I used that way for about 6 months, until they were eventually fixed.

As said, the now changed APIs are probably more rare, so hopefully the impact is not as wide spread as it was back then. Still I would not be surprised to see some fallout and complications from this, but maybe I worry too much. I just wished we could have done this a bit smoother this time around.

Since the staged solution was mentioned briefly in the PR review, what was the rationale for opting to not take that route? Just forgotten? I can certainly understand that too, we all have a lot on our plates and sometimes things slip through.

Anyway thanks again for the quick reply and let's hope it does not cause as much complications as I fear. There is of course also advantages with just doing a clean cut and taking the breaking changes in one blow. It gets done and over with quicker. 😃

Kind regards, Mike

[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.