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.
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"!)
Most people think of package deps in terms of packages, not unibuilds,
but our constraint solver has all these generated "if you're using
foo#os@1.0.0, use foo#web.browser@=1.0.0" constraints. They are just
distracting in errors (which already hide the unibuild part for
clarity) so make sure we don't see them in paths either.
(I could imagine a flag/env var that skips all the removeUnibuild calls
and this special processing, for "gory details" mode.)
We were not passing html attributes through to the Boilerplate object,
so appcache manifest was never showing up in the <html> tag. Add
'extraData' to `Boilerplate.toHTML` so that we can specify the html
attributes at request time.
