Consider building or analyzing plugins a second time with the latest iOS version #102835
Labels
c: contributor-productivity
Team-specific productivity, code health, technical debt.
p: tooling
Affects the flutter_plugin_tools package
P2
Important issues not at the top of the work list
package
flutter/packages repository. See also p: labels.
We routinely get bugs, and sometimes PRs, about deprecation warnings in our plugins that only show up when building for a higher minimum version of iOS than we support. It would be nice if we caught that in CI so that we'd have enforcement of adding deprecation warning suppression pragmas as part of writing the code, instead of people filing bugs about it.
If it's not too time-intensive, we could have the plugin tooling know how to modify the example apps locally to the latest iOS version, and then we could run that step and then re-run build or analyze (whichever is cheaper) with warnings as errors, to catch use of anything that's deprecated but not pragma'd. (Or not necessarily the absolute latest; we could pick some new-but-not-too-new version to catch most cases, but not force us to immediately handle all deprecations, and then roll it forward once a year and add any new pragmas. Presumably not a lot of people are only supporting the absolute latest iOS.)
(This assumes that we are in fact treating warnings as errors in this scenario; see discussion in #91868)
/cc @jmagman
The text was updated successfully, but these errors were encountered: