Hello,
It seems that Pub is analyzing Flutter packages using a channel different than stable (currently v1.5.8).
This causes issues because there are multiple breaking changes between stable and the latest version of master.
@rrousselGit: I'm sorry that we were breaking you, I'll make sure that we have checks for this going forward.
Cool, thanks!
Alternatively, from a quick look into this repo's code: it seems that for pure dart packages the dart SDK used changes if the package version is suffixed by -dev or not.
It may be interesting to do the same thing for Flutter SDK.
from a quick look into this repo's code: it seems that for pure dart packages the dart SDK used changes if the package version is suffixed by -dev or not.
Actually, after the Dart 2 stable release we have adapted the policy to only support stable SDKs for analysis. We may use non-stable SDK for running the site, but that is a separate concern from what we are using for the packages.
/cc @mit-mit
https://pub.dev/packages/flutter_image_compress#-analysis-tab-
One problem is that I uploaded a new version of the package today.
I added a 1.5.9 constraint because a breaking change in flutter made my package unusable in version 1.5.9 or above, but it seems that the flutter SDK version of pub does not support version 1.5.9+.
Now flutter dev channel is 1.6.0, so how should I do?
@jonasfj @sigurdm @mit-mit: we have contradicting requests with this issue and #2290, and we'll need to define a policy that is aligned with how the Flutter SDK is moving forward.
What about parsing the sdk constraints and picking the latest available version?
This could be combined with a CRON to rerun the analysis on a daily/weekly
Option A:
What about parsing the sdk constraints and picking the latest available version?
Option B:
We only analyze with stable version and display a grey score of ??? whenever we detect that we're unable to do analysis. I'm not exactly sure, but we could detect and display that we can't analyze things.
In either case, we should probably add a flag to packages that depend on dev versions of either flutter or dart-sdk. Such that users are warned.
I'm not sure there is a quick fix here. If you're targeting dev versions we should warn users, either by flagging the package or by failing to analyze / giving a lower score.
Note. I'm not saying it's a bad idea to target a dev version, I'm just saying that when you do it -- users should be warned. Besides the warning will go away when a stable release is made :)
Do you think it is possible to deploy multiple analyzers?
Stable uses stable, dev uses dev.
Decide which analyzer to use based on the SDK constraints in pubspec.yaml.
@CaiJingLong it's possible, but we are not sure the extra complexity is warranted. In any case, let's track that request in https://github.com/dart-lang/pub-dartlang-dart/issues/2283
Latest stable release of Flutter is 15/4-hotfix.2: https://flutter.dev/docs/development/tools/sdk/releases?tab=macos
We should downgrade to that.
Agreed that dynamic versioning may be too complex.
Running on stable only should be enough.
On the other hand, it's probably a good idea to send a mail to the packages authors if the health score decreased after the analysis ran on a newer version.
Awesome!
Do I need to publish something for the analyzer to run again, or it this automatical?
@rrousselGit It will be running automatically with the new runtime environment once we deploy a new pub site version.
A new Flutter stable version is available.
Can we reopen this to switch to using 1.7.x?
@rrousselGit tracking it in #2464, update merged, deployment already made, we are 5% traffic on the new release, will be 100% tomorrow.
Will this update analyze previous releases?
@renancaraujo: yes, we always re-analyze previous releases (up until they are two years old).
I switched all traffic over to newest deployment. You'll not need to do anything, we automatically reanalyze.
Most helpful comment
@rrousselGit It will be running automatically with the new runtime environment once we deploy a new pub site version.