SDK Constraints and Dart 2

[Natalie Weizenbaum]

Hey Dartisans,

Work is ramping up on Dart 2.0.0, and that’s raised some questions about packages’ SDK constraints. Many packages currently have an SDK constraint that ends with <2.0.0, disallowing all Dart 2.0.0 SDKs. Some have no SDK constraint at all, although this will be interpreted as a default constraint in Dart 2. This means that if Dart 2.0.0-dev.1 were released today, it wouldn’t see any packages at all. We need a plan to make packages available, so we can get real-world code running on the 2.0.0 dev SDKs.

There are breaking changes planned for Dart 2.0.0, so some existing packages probably won’t be compatible with the eventual 2.0.0 stable release. What’s more, breaking changes may happen throughout the 2.0.0 dev cycle as features evolve and user feedback is taken into account, so there’s no way to know for sure whether a package will work with the next 2.0.0-dev release.

The most conservative option would be to assume every 2.0.0-dev release is breaking when choosing SDK constraints. So if my package were compatible with the current release, let’s say 2.0.0-dev.3, its SDK constraint would be >=1.0.0 <2.0.0-dev.4. But this means we’d need to release a new version of every package for every single 2.0.0-dev release. Not only would that be a huge burden for package maintainers, it would mean users of the dev branch would experience weekly version lock until every package they used updated.

So instead, the plan is to use an upper bound of <2.0.0-dev.infinity for all packages’ SDK constraints. This declares compatibility with every dev release of Dart 2.0.0, but not with the eventual stable release. Users may run into package versions that are incompatible with their SDK in practice, but only if they’ve opted into using the unstable 2.0.0-dev SDK. In return, in the common case where a release doesn’t break packages, those packages will be immediately available.

If you’re a package author, you should update your packages’ SDK constraints to <2.0.0-dev.infinity and publish a patch release sooner than later—2.0.0-dev.1 is on the horizon. You should also keep an eye on this mailing list for breaking changes that affect your package, so you can update it when they land and keep your users from breaking.

If you’re a package user, you don’t need to take any immediate action. Just be aware that using a 2.0.0-dev release will mean that SDK constraints are squishier than usual, and you’ll probably need to run pub upgrade more often to make sure your dependencies are compatible with the latest and greatest Dart has to offer.

- Natalie

[Игорь Демьянов]

In my opinion, it's better to make "environment_overrides". Similarly to 'dependency_overrides'. This will solve the problem of testing on "real" packages. The packages will then migrate to 2.0

четверг, 13 июля 2017 г., 1:53:26 UTC+3 пользователь Natalie Weizenbaum написал:

[Günter Zöchbauer]

or just adding the dependencies to dependency_overrides:

[Danny Tuppeny]

On Wed, 12 Jul 2017 at 23:53 'Natalie Weizenbaum' via Dart Misc <mi...@dartlang.org> wrote:

If you’re a package author, you should update your packages’ SDK constraints to <2.0.0-dev.infinity and publish a patch release sooner than later—2.0.0-dev.1 is on the horizon. You should also keep an eye on this mailing list for breaking changes that affect your package, so you can update it when they land and keep your users from breaking.

Isn't this going to make it really difficult to tell which packages are known to work for a v2 dev version versus known to not work? If you want to migrate an app (or even a package with other dependencies) you need a good idea of which of your dependencies will work in v2 and this seems to remove a (fairly) reliable method of telling that - knowing what version the author has deemed it tested it with. I'd rather the unknowns were considered "not working" than "working" and wait until the package authors have tested them before I start upgrading stuff.

(I don't actually have anything to update and I have limited experience with pub packages; I'm just thinking out loud.. this might be nonsense!)

[Natalie Weizenbaum]

On Thu, Jul 13, 2017 at 10:27 AM, Danny Tuppeny <da...@tuppeny.com> wrote:

Isn't this going to make it really difficult to tell which packages are known to work for a v2 dev version versus known to not work? If you want to migrate an app (or even a package with other dependencies) you need a good idea of which of your dependencies will work in v2 and this seems to remove a (fairly) reliable method of telling that - knowing what version the author has deemed it tested it with. I'd rather the unknowns were considered "not working" than "working" and wait until the package authors have tested them before I start upgrading stuff.

Honestly? Yes it will, and that sucks. I don't think there are any planned breaking changes that are likely to cause too much havok, but there may well be times when you'll have to just manually test packages to see if they work on the latest SDK. It's an extra price to pay for using the 2.0.0-dev line, and I'd certainly rather not incur that. But the alternative is a much higher price: constant version lock for users and constant demands on package authors' time.

There's no painless way to handle a range of versions where breaking changes may happen at any time. Breaking changes are inherently painful. But it's a productive kind of pain: every break represents an improvement in the languages or the libraries that will provide dividends forever after.

[Danny Tuppeny]

On Thu, 13 Jul 2017 at 20:23 'Natalie Weizenbaum' via Dart Misc <mi...@dartlang.org> wrote:

Honestly? Yes it will, and that sucks. I don't think there are any planned breaking changes that are likely to cause too much havok, but there may well be times when you'll have to just manually test packages to see if they work on the latest SDK. It's an extra price to pay for using the 2.0.0-dev line, and I'd certainly rather not incur that. But the alternative is a much higher price: constant version lock for users and constant demands on package authors' time.

To be honest, I don't know the scale of the breaks being made. There was talk of strong-mode being the only option in the recent blog post so I assumed that a) that was part of v2 and that b) it'll pretty much break every package. I don't know if either of those are correct. Seems like you've weighed things up and I'm aware I'm probably the least qualified person here to have an opinion on it! =D

Don't know if this is the best place (forum or thread!) to ask, but I presume the v2 dev builds will be the same as any other, eg. they'll include snapshots for the analyzer service, etc.? I think flutter currently runs on dev builds too, but I presume they won't immediately jump to v2 devs builds?

[Natalie Weizenbaum]

On Thu, Jul 13, 2017 at 12:37 PM, Danny Tuppeny <da...@tuppeny.com> wrote:

To be honest, I don't know the scale of the breaks being made. There was talk of strong-mode being the only option in the recent blog post so I assumed that a) that was part of v2 and that b) it'll pretty much break every package. I don't know if either of those are correct. Seems like you've weighed things up and I'm aware I'm probably the least qualified person here to have an opinion on it! =D

Strong mode will be the only mode, but it won't break very much. Package authors have had a long time to get their packages compatible with strong-mode, and essentially all widely-used Dart packages have been compliant for a good long time now. I expect other breaks to be fairly narrow in scope.

Don't know if this is the best place (forum or thread!) to ask, but I presume the v2 dev builds will be the same as any other, eg. they'll include snapshots for the analyzer service, etc.? I think flutter currently runs on dev builds too, but I presume they won't immediately jump to v2 devs builds?

My understanding is that they'll be the same as existing dev builds, but with different version numbers and with greater license to make breaking changes. I'm not sure what exactly Flutter will pull from, though.

[Kevin Moore]

FYI: We've updated our guidance here – please see http://news.dartlang.org/2017/09/dart-20-pre-releases-what-they-mean-to.html

You DO NOT need to add an upper bound of 2.0.0-dev.infinity. In fact, this will make using a package w/ an bleeding edge build impossible.

Thanks!