-
Notifications
You must be signed in to change notification settings - Fork 309
settings: Upgrade Flutter; migrate to new RadioGroup API #1546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
And update Flutter's supporting libraries to match, and take an automatic update to the iOS Info.plist file.
This tests the observable behavior more directly. RadioListTile.checked has been deprecated (zulip#1545), so we'd like this test to stop relying on that implementation detail.
This migration is verified by the tests that we touched in the previous commit; they ensure that the buttons' checked state still updates visibly. Fixes: zulip#1545
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks LGTM!
Also, no additional changes to the macOS/iOS Podfile
/Podfile.lock
when doing flutter run
on my side.
Hmm actually—it looks like the Info.plist thing is a breaking change: flutter/flutter@3d8fa621c From my reading of the commit and the migration guide linked from there, it looks like it wouldn't break our |
Right, also looks like the migration/fix for that is going to be a bit involved. (See discussion here: https://discord.com/channels/608014603317936148/1380539391671275662) Also, I saw a report of deep links being broken, which led me to test the web auth flow in our app on iOS Simulator and unfortunately it turns out that we are affected by it too (verified by switching back and forth between that and the parent commit). I'll file an upstream issue (in a bit, with a reproducer) if the reporter doesn't already have it by then. Edit: Filed flutter/flutter#170350. |
Thanks for investigating! |
Given the breakage of web auth, let's plan to not upgrade Flutter past that commit until after the launch. (Even if it gets fixed upstream this week, time is getting short before the launch.) The migration those upstream changes require in #1379 would also be enough to make it tempting to hold off on upgrading until after the launch. @chrisbobbe Does the upstream change that's needed for the #1545 fix happen before the UIScene breaking change? If so, let's upgrade to that point. If not, we can just put ignore-comments on those deprecation warnings for now, and update #1545 to be about removing those ignore-comments. |
Hmm, no, the change needed for #1545 (flutter/flutter@d0058ec36) happens after the UiScene breaking change (flutter/flutter@3d8fa621c):
So yeah, I'll close this and do this:
|
See zulip#1546 for a PR that would resolve them, and why we're not doing that just now (it would require upgrading Flutter past a breaking change).
See zulip#1546 for a PR that would resolve them, and why we're not doing that just now (it would require upgrading Flutter past a breaking change).
Fixes: #1545