It was broken because fake-warehouse and test-package-server were
incompatible. In order to actually use the published packages, we had
to sync test-package-server into the local warehouse. But as soon as we
did that, the latest release became some other random release.
In any case, the semantics tested here have changed twice since 0.9.0!
In 0.9.0.1 we changed it from "ask for any RC means get any RC" to
"don't get any RCs that aren't explicitly anticipated". And in 1.1
we're changing it to "minimize unanticipated RCs".
Manually running through the equivalent of this test, most of it works
except for the last line; `meteor update` will not take you from one RC
to the next, due to minimizing unanticipated RCs. That's probably fine
though.
While we're at it, make it much more clear that warehouse and
test-package-server don't work together.
Don't throw errors about changing versions of root dependencies from
the previous solution if the package has a top-level equality
constraint like foo@=1.2.3.
This avoids the need for --allow-incompatible-update in a variety of
cases that it isn't really designed for:
* Core package versions changing when switching branches or changing
between prereleases.
* Scenarios where you override a core package
* Adding an explicit equality constraint: `meteor add foo@=1.2.3`
(you will still be prompted to pass --allow-incompatible-update
if the constraint is inexact, like foo@1.2.3).
Fixes the 'list-with-a-new-version' self-test, 'package-depends-on-
either-version', and probably 'old cli tests'.
Undocumented flag. This is one of those cases that is rare but may
come up, because `meteor list` runs the version solver (and writes
.meteor/versions). For example, it may come up if you run `meteor
list` with PACKAGE_DIRS and then without (or vice versa). You'll
get a message that says to pass --allow-incompatible-update, so we
must support it.
