Restrict the version constraints on exported dependencies.

Restrict the version constraints on exported dependencies.

This avoids a versioning issue where an exported dependency adds a
feature and the exporting package's users' version constraints become
invalidated.

For example, suppose unittest 1.0.0 and matcher 1.0.0 exist. unittest
has the constraint "matcher: '>=1.0.0 <2.0.0'" and exports matcher.
Then matcher 1.1.0 is released with a new feature, and a user writes a
new package, mypkg, which uses that feature. As per common practice,
this package has the version constraint "unittest: '>=1.0.0 <2.0.0'"
and no constraint on matcher. This constraint allows matcher 1.0.0,
which doesn't support the new feature; this is a problem.

Under the new scheme, unittest would have the constraint "matcher:
'>=1.0.0 <1.1.0'". Then when matcher 1.1.0 is released, unittest 1.1.0
would be released as well with the constraint "marcher: '>=1.1.0
<1.2.0'".

The tight lower bound ensures that the constraint "unittest: '>=1.1.0
<2.0.0'" properly selects only versions of matcher that have features
available in the version the user is testing against. The tight upper
bound ensures that new features in a new version of matcher won't
become available in unittest without a version upgrade.

R=jmesserly@google.com, rnystrom@google.com

Committed: https://code.google.com/p/dart/source/detail?r=42223

[nweiz, 2014-12-04 22:46:56]

nweiz@google.com changed reviewers:
+ rnystrom@google.com, sigmund@google.com

[Jennifer Messerly, 2014-12-04 23:05:19]

jmesserly@google.com changed reviewers:
+ jmesserly@google.com

[Jennifer Messerly, 2014-12-04 23:05:20]

polymer LGTM

https://codereview.chromium.org/775413002/diff/1/pkg/polymer/pubspec.yaml
File pkg/polymer/pubspec.yaml (right):

https://codereview.chromium.org/775413002/diff/1/pkg/polymer/pubspec.yaml#new...
pkg/polymer/pubspec.yaml:29: observe: '>=0.12.2 <0.12.3'
Nice solution. Thanks so much for tracking this down!
BTW, we could just remove this re-export from Polymer. It's not worth it, IMO.
In fact, new Polymer 0.8 doesn't depend on observe-js so the timing is perfect.
But naturally feel free to defer that to Jake or Siggi, since it would be a
major version bump. Up to you :)

[Siggi Cherem (dart-lang), 2014-12-04 23:26:28]

On 2014/12/04 23:05:20, John Messerly wrote:
> polymer LGTM
> 
> https://codereview.chromium.org/775413002/diff/1/pkg/polymer/pubspec.yaml
> File pkg/polymer/pubspec.yaml (right):
> 
>
https://codereview.chromium.org/775413002/diff/1/pkg/polymer/pubspec.yaml#new...
> pkg/polymer/pubspec.yaml:29: observe: '>=0.12.2 <0.12.3'
> Nice solution. Thanks so much for tracking this down!
> BTW, we could just remove this re-export from Polymer. It's not worth it, IMO.
> In fact, new Polymer 0.8 doesn't depend on observe-js so the timing is
perfect.
> But naturally feel free to defer that to Jake or Siggi, since it would be a
> major version bump. Up to you :)

Yeah, for now, I'm inclined to keep it @observable is used heavily and people
will have to change a lot of files to include it. I think we should do the
change, but together with the roll for 0.8.

[Bob Nystrom, 2014-12-05 18:09:26]

scheduled_test and unittest changes LGTM!

[nweiz, 2014-12-09 21:35:33]

Committed patchset #1 (id:1) manually as 42223 (presubmit successful).