Pre-release SDK constraints should not require a pre-release version

[grouma]

The following error should only be a warning:

Packages with an SDK constraint on a pre-release of the Dart SDK should themselves be published as a pre-release version.

See this specific example: dart-lang/build#2753

[jakemac53]

This should be a warning only, otherwise breaking changes in dev sdk's cannot be fixed for users without them explicitly updating to dev releases of their (possibly transitive) dependencies.

Pre-release packages are deprioritized in pub solves so you will end up with only the stable version by default.

There are also other situations where you know it is safe to depend on something from a dev sdk (see the linked example).

[grouma]

Note this is completely blocking. Dropping back to an older SDK (2.7.0) still has this issue. Dropping back further requires a now optional author field.

This issue appears to even be in version 1.24 :/

[grouma]

Looks like this is actually server side: #3607

[jakemac53]

Note that this is also not going to work nicely with our NNBD roll-out strategy. We want to have the core ecosystem packages (at least those required to run tests) published and ready to go as soon as nnbd is released. The strategy of releasing those packages as non-breaking versions is heavily reliant upon them being available the first time any user on the new sdk runs pub upgrade (although yes, there is no guarantee users will actually be able to get those versions anyways).

We could possibly publish packages with a stable sdk constraint on an SDK which doesn't yet exist (no idea if pub allows this or not). At a minimum that would tank the pub score of the packages.

Otherwise we would be stuck having to scramble to publish these packages once the sdk does land, which we can't realistically do in as quick of a timeframe as we would like.

We would instead prefer to add a constraint like >=2.10.0-0 <2.11.0 (which allows both the 2.10 dev sdk as well as stable). We would only do that once dev is in fact stabilized (possibly after cutting the stable branch).

cc @leafpetersen

[jonasfj]

This was discussed in #3557.

I don't feel particularly strongly about it. The fact that we don't enforce the transitive variant of this property makes it seem less useful to me.

On the other hand, a stable SDK release should not break packages. If it does this is liable to cause pain because our SDK upper-bound constraints are wrong. That said, I see how it's sometimes necessary and reasonable to work around.

NB. if we decide to change this, we can easily fix it on the server.

[jakemac53]

I guess I missed the response to my concerns in the original discussion there :/.

[sigurdm]

cc @mit-mit surely wants to weigh in here.

[leafpetersen]

I'm pretty concerned about making this an error. We're having a lot of problems right now with our processes already requiring too much atomicity, and I'm quite worried that this might exacerbate the problem.

[jakemac53]

Consider also the following scenario for any package depended on by flutter:

1. The SDK releases some new feature that a package wants to use.
2. The package starts using it, and has to stay at a pre-release version.
3. We start preparing the stable flutter/dart sdks, and want to update to the latest version of said package in flutter.

• We cannot publish a stable version of the package because it depends on a dev SDK, and the stable SDK is not yet released
• At the same time flutter stable should really not be pinning dev releases of packages (null safety being the exception right now, but not likely a strategy we want to repeat)

How do we resolve this scenario? Do you have to wait two stable releases before using any new sdk feature in a package depended on by flutter?

[grouma]

Consider also the following scenario for any package depended on by flutter:

The SDK releases some new feature that a package wants to use.

This is the exact scenario that caused issues outside of Flutter. The Dart SDK began writing metadata files that we wanted to consume from package:dwds. It blocked us from publishing a non dev version of package:webdev.

[nshahan]

As another data point for the discussion, this issue is blocking publishing a new version of the package dart_internal that works with the sdk v2.9.0. 9 of the 10 published versions of the package have already been published with a lower sdk bound of 2.0.0-dev.12.0. Should I have to arbitrarily bump the lower bound to publish?

See the history of commits to the pubspec: https://github.com/dart-lang/sdk/commits/master/pkg/dart_internal/pubspec.yaml

[jakemac53]

This is now blocking us from fixing a real issue, dart-lang/build#2763

All users will have to pin analyzer or build_runner on the flutter release that corresponds to version 2.10, and we cannot publish a fix that does not break users of 2.9 because of this arbitrary restriction.

[leafpetersen]

Jake's comment should be "this is now blocking".

cc @athomas @jonasfj @sigurdm we really need to revert this change (or make it a warning) and reconsider at leisure. Are any of you around to do this on Friday (AAR time) so that we can land the fixes early Friday morning SEA time?

[jonasfj]

I'm back Monday. Let's look at it next week :)

…

On Fri, 31 Jul 2020, 06.30 Leaf Petersen, ***@***.***> wrote: Jake's comment should be "this is now blocking". cc @athomas <https://github.com/athomas> @jonasfj <https://github.com/jonasfj> @sigurdm <https://github.com/sigurdm> we really need to revert this change (or make it a warning) and reconsider at leisure. Are any of you around to do this on Friday (AAR time) so that we can land the fixes early Friday morning SEA time? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/dart-lang/pub/issues/2557#issuecomment-666911913>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABERZFNCNPVMKHSBMSQ3QDR6JCFXANCNFSM4OYWFVPQ> .

[jakemac53]

that was... quite the typo 😆 - fixed