-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
[all_packages] Enforce property assignment for compile sdk over method assignment #8897
[all_packages] Enforce property assignment for compile sdk over method assignment #8897
Conversation
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.
Tool changes LGTM, but I'm still seeing ~40 violations of this locally.
if (methodAssignmentLine == null) { | ||
printError('${indentation}No compileSdk or compileSdkVersion found.'); | ||
} else { | ||
printError('${indentation}No compileSdk = found. Please use property assignment.'); |
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.
How about No "compileSdk =" found
to make this easier to parse if you don't already know what the issue is?
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.
Done
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.
LGTM. All comments optional.
@@ -24,7 +24,7 @@ if (flutterVersionName == null) { | |||
|
|||
android { | |||
namespace = "com.example.all_packages" | |||
compileSdkVersion flutter.compileSdkVersion |
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.
Do we actually want to change this one? If we somehow broke it (maybe that's not even possible, but then... gradle), we would want to know presumably. And this is what the template generated at the time.
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.
I can see the argument for leaving it, it is code that we once generated.
That said what would break is not our code but agp code and I decided removing the last instance of compileSdkVersion was a good idea. If you feel strongly then I can revert this. I do not think gradle check runs against the legacy project so it wont cause a breakage.
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.
That said what would break is not our code but agp code
If that happened we would want to put in a Flutter Fix or an auto-migrator though, presumably? Getting a warning about needing to do that from our CI could be nice.
I decided removing the last instance of compileSdkVersion was a good idea. If you feel strongly then I can revert this.
I would lean toward leaving it the way it was since in general the idea of legacy_project
is to make absolutely minimal changes to it, but I'm fine with you making a call on it either way.
I do not think gradle check runs against the legacy project so it wont cause a breakage.
Right, the check runs on individual packages, and won't include this file.
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.
reverted.
|
||
|
||
defaultConfig { | ||
// TODO: Specify your own unique Application ID (https://developer.android.com/studio/build/application-id.html). | ||
applicationId "io.flutter.plugins.flutter_plugin_android_lifecycle_example" | ||
minSdkVersion flutter.minSdkVersion | ||
minSdkVersion = flutter.minSdkVersion | ||
targetSdkVersion flutter.targetSdkVersion |
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.
Why minSdkVersion
but not targetSdkVersion
?
Is the plan just to wait and fix the assignment type when standardizing on targetSdk
?
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.
accidental add, removing. I do want to move us to use equals and minSdk and targetSdk but only with the enforcement to keep it that way.
@@ -421,12 +421,21 @@ for more details.'''; | |||
|
|||
bool _validateCompileSdkUsage( |
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.
Do we want to enforce the ndkVersion
style too?
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.
Eventually, I reverted the min change but most of the ndk versions were adjacent to the compileSdk so I went ahead and did them. I am willing to revert the ndk changes if you want to enforce it with tooling. That said I dont see a world where ndk tooling is important enough to enforce. I do think I will add enforcement for minSdk and targetSdk.
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.
If we care about it I think we should eventually enforce it, but I don't see any reason to block incidental updates while touching surrounding code on enforcement.
autosubmit label was removed for flutter/packages/8897, because - The status or check suite Linux_web web_dart_unit_test_wasm_shard_2 master has failed. Please fix the issues identified (or deflake) before re-applying this label. |
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.
LGTM
Failures appear unrelated. Hopefully an updated branch will fix the issue. |
autosubmit label was removed for flutter/packages/8897, because - The status or check suite Linux_web web_dart_unit_test_wasm_shard_2 master has failed. Please fix the issues identified (or deflake) before re-applying this label. |
Blocked on flutter/flutter#165664 |
Clicked "Update branch" because web tests seem to be fixed in master after @stuartmorgan's fix. |
autosubmit label was removed for flutter/packages/8897, because - The status or check suite Mac_arm64 ios_platform_tests_shard_2 master has failed. Please fix the issues identified (or deflake) before re-applying this label. |
I'm seeing this same issue on a roller PR. I'm wondering if it's OOB failure from a maps SDK or server change. |
Looking at the build history for the suite, it seems this was the first build broken like this was on: 2025-03-25 @ 09:55: Associated to this commit:
|
Once #8967 lands, merging in |
…over method assignment (flutter/packages#8897)
flutter/packages@07496eb...4a36dc6 2025-04-03 [email protected] [all_packages] Enforce property assignment for compile sdk over method assignment (flutter/packages#8897) 2025-04-03 [email protected] [google_maps_flutter] Fix iOS info window regression (flutter/packages#8939) 2025-04-02 [email protected] Roll Flutter from 05b5e79 to a0b1b32 (37 revisions) (flutter/packages#8985) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-packages-flutter-autoroll Please CC [email protected] on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
…d assignment (flutter#8897) No issue I just noticed that we were almost consistent in our approach to compileSdk.
No issue I just noticed that we were almost consistent in our approach to compileSdk.
dart format
.)[shared_preferences]
pubspec.yaml
with an appropriate new version according to the [pub versioning philosophy], or I have commented below to indicate which [version change exemption] this PR falls under[^1].CHANGELOG.md
to add a description of the change, [following repository CHANGELOG style], or I have commented below to indicate which [CHANGELOG exemption] this PR falls under[^1].///
).