Open jacob314 opened 1 year ago
It seems to me that any app that is under active development is going to have more results (no matter how they're measured) than apps in maintenance mode. I don't know how we'd counter that skew.
That said, another possibility to consider would be to record the minimum SDK constraint for analyzed packages. That would tell us about adoption of all language features, both null-safety and others in the future.
What's the priority of this work?
recording the minimum SDK constraint sounds good. I'd say that is a P2 assuming it is easy to log. Other more complex metrics are probably P3.
Do you see this as necessary at this point in Dart 3+ releases? Or did you mean for these analytics to be released in older versions of the SDK, or for use in understanding the usage of future features?
My understanding is that almost all of the remaining usages of Dart 3+ SDK releases that are still using unsound mode are within Google, since trying to use unsound mode outside is unsupported, inconsistent between tools, and hidden. I'd be surprised if many developers have been doing it rather than sticking to an earlier SDK release.
Right now we struggle to understand how much non-null safe Dart usage is left and whether the non-null safe Dart usage is maintenance mode usage or active development where users are adding new package dependencies and relying on websites such as pub.dartlang.org.
We currently track the % of all Flutter run commands without sound null safety. This # may overstate the % of Flutter apps under active development using sound null safety as most unsound apps may be in maintenance mode with only minor local tweaks.
What would be more actionable is the number of flutter apps run without sound null safety that are still in active development. Possible analyzer analytics to track this: