[dart-misc] SDK Constraints and Dart 2

['Natalie Weizenbaum' via Dart Misc]

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 <https://github.com/dart-lang/pub/issues/1657>. 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

Post by 'Natalie Weizenbaum' via Dart Misc
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 <https://github.com/dart-lang/pub/issues/1657>. 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

[Günter Zöchbauer]

Post by Игорь Демьянов
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

Post by 'Natalie Weizenbaum' via Dart Misc
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 <https://github.com/dart-lang/pub/issues/1657>.
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

[Danny Tuppeny]

On Wed, 12 Jul 2017 at 23:53 'Natalie Weizenbaum' via Dart Misc <

Post by 'Natalie Weizenbaum' via Dart Misc
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' via Dart Misc]

Post by Danny Tuppeny
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 <

Post by 'Natalie Weizenbaum' via Dart Misc
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' via Dart Misc]

Post by Danny Tuppeny
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

Post by Danny Tuppeny
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' via Dart Misc]

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!

Post by 'Natalie Weizenbaum' via Dart Misc

Post by Danny Tuppeny
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

Post by Danny Tuppeny
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.