Pub-dev: Ability to support dev-only versions on pub

[lambdabaa]

I would like to be able to publish a package to pub and have it analyze with a dev version of the Dart SDK.

[isoos]

Hi @lambdabaa. Right now we only analyse with the stable SDKs, and the current upgrade process for them is manual. We have long-term plans to automatically and dynamically use the latest (possibly dev) SDKs, but it is unlikely to happen in the next few months.

[jakemac53]

Imo the ideal solution here would be to use the sdk that matches the minimum sdk constraint in the pubspec.

EDIT: On second thought that sdk might not be able to fetch all the latest deps so that might not work either.

[lambdabaa]

Hi @lambdabaa. Right now we only analyse with the stable SDKs, and the current upgrade process for them is manual. We have long-term plans to automatically and dynamically use the latest (possibly dev) SDKs, but it is unlikely to happen in the next few months.

Thanks for the heads up. This is not an urgent need but I wanted to throw out the feature request for consideration and discussion. Currently both version solving and running dartanalyzer work locally and on CI for https://github.com/dart-lang/tflite_native, so as a user the behavior on pub has a mismatch with my expectations. I totally agree with your assessment that this isn't a super high priority though.

[ditman]

+1 We're having the same issue with flutter for web plugins (example: 1, 2), where our Dart + Flutter versions need to be newer than stable; to have extension methods or new pubspec formats available.

I guess we can republish to retrigger an analysis when newer versions make it to pub.dev!

[isoos]

I guess we can republish to retrigger an analysis when newer versions make it to pub.dev!

Note: pub.dev will re-analyze the package every time we do upgrade the tooling SDKs (and also if the dependency of you package changes), there is no need to republish a package for the sake of re-triggering analysis.

[ditman]

That's good to know @isoos! We'll just wait, then. Thanks!

[jakemac53]

Note that the latest mockito is running into this now as well, as it depends on a version of test_api that requires a dev release.

On top of that, it appears that the documentation link for the previous version redirects to the "latest" version, which of course doesn't exist, so you can't get any docs at all.

Can we re-open this for consideration?

[isoos]

https://github.com/dart-lang/pub-dev/issues/2762#issuecomment-683142968 is already open and reported on.

[jakemac53]

Right, but this is an issue for the more general feature that would prevent this from happening in the future

[isoos]

We don't have the infrastructure to follow prerelease SDKs, nor have immediate plans to implement it. If you depend on a prerelease SDK, maybe the package should be prerelease itself. That way the latest stable version can be on a stable SDK which and have the appropriate dartdoc.

[jakemac53]

Regardless of the debate about whether it is valid to release stable versions of packages that depend on dev sdks, those packages should still be analyzable, imo (even the pre-release versoins). They are totally valid packages.

[isoos]

Regardless of the debate about whether it is valid to release stable versions of packages that depend on dev sdks, those packages should still be analyzable, imo (even the pre-release versoins).

Agreed. However we do need to improve other parts of the pub.dev infrastructure before this can happen.

They are totally valid packages.

The expectations are slightly different, as the majority of the users would want to have packages working on stable SDKs.

[jakemac53]

Agreed. However we do need to improve other parts of the pub.dev infrastructure before this can happen.

Ya, I am not asking for an immediate fix here, but just to keep tracking this as something that we eventually plan on resolving.

The expectations are slightly different, as the majority of the users would want to have packages working on stable SDKs.

The packages absolutely do work on the latest stable sdk - just not necessarily the absolutely latest version of the package. This makes complete and total sense, and there is nothing wrong with doing this. It is in fact _required_ that you do this sometimes.

• Sometimes the SDK releases breaking changes for which you cannot do a backwards compatible fix - in order to release a bug fix for dev sdk users only you have to do this. You cannot reliably use a pre-release for this purpose (all your users would have to manually depend on that pre-release).
  
  
  
  • Sometimes you want to release new behavior that requires some feature that is only available on a dev release, and you want all users of the dev sdk to pick it up by default.
  
  

Why would we want to punish both the users and producers of packages that are in this state?