As of 3e64bd78, this usage of `reload` no longer works (if we set a
project's root dir to a fresh app, and then run the app which computes
versions.json, and then call `reload`, we'll end up with the project's
dependencies being empty). Maybe this is a bug in `reload`, but it
probably doesn't matter for any usage other than this test, and maybe
this test was misusing `reload` in the first place.
This allows us to later increase the pool for well-formed versions without requiring
moving the catalog's data.json into a new folder, which would require re-syncing
the entire catalog.
1. Fixes the test for updating to a new rc. First, change the ordering -- since we order RCs now, it means that if you add rc.3 while
rc.4 is available it just adds rc.4. So, now, we publish rc.4 after rc.3 has been added, run update (with the right options) and
check that it worked.
2. When you run list, we check if there are newer versions of packages. Usually we just look at mainline versions. But if you are already
using an rc version of a package, you might care about new rcs too. So, in that case, we check the latest of *all* available versions.
Previously, if we were asking for a pre-release, we would only return true if it was the
same pre-release, or at least on the same release. But that's not true. 1.2.4 should be valid
if we want 1.2.4-rc0, for example, and, even 1.2.3-rc0. (I mean, if it has the same ecv, which
it might not). This is also what was causing some of the issues around 0.9.1 rollout, we think. So,
we are going to try treating rcs like normal versions as far as comparisons go. We still don't want to
give you an rc unless you asked for it though.
It's now back to returning 10000 for "1.0.0", as it was before
the recent changes to allow for wrapped package version numbers
and prerelease versions. Given that there are other constants
in the cost function used in the constraint solver, this gives
us much more confidence that we haven't fundamentally changed
the behavior of `meteor add` or `meteor update` in 0.9.3.
It's now back to returning 10000 for "1.0.0", as it was before
the recent changes to allow for wrapped package version numbers
and prerelease versions. Given that there are other constants
in the cost function used in the constraint solver, this gives
us much more confidence that we haven't fundamentally changed
the behavior of `meteor add` or `meteor update` in 0.9.3.
The semver library's compare functions already did the right thing,
but our `PackageVersion.versionMagnitude` did not. It now almost
correctly works for prerelease versions with a few caveats described
in a [* XXX!] comment.
While at it, add many tests which caught a separate bug due to
adding a number to a string for versions such as "1.2.3_50".
(That version would have been chosen over "5.0.0"!)
