Other approaches seemed to be heuristics that broke down in edge cases:
a timeout wasn't guaranteed if your JS was slow; page.load in PhantomJS
wasn't firing reliably because of long polling.
Not sure what the original motivation for printing <unknown> was (it
shouldn't ever come up in normal operation, only if something weird
happens like we manually unset a user's username in the database). But
it's now rather inconvenient because we don't yet clean up deleted
organizations from a site, so you would see <unknown> for every
authorized organization that has been deleted. While we should
eventually clean up deleted organizations from a site's
"authorized_orgs" field, for now this will clean up the output of this
command.
Replace catalog.getLatestVersion with catalog.getLatestMainlineVersion,
which skips prerelease versions (those with dashes in the
version). Ensure that this function is only used by high-level commands
like 'meteor list'. Replace other uses of that function with other
equivalent functions.
Also, don't stack trace on 'meteor add' constraint failure.
Before, we were running the constraint solver with both the new and the
old constraint, which would fail if they were not simultaneously
satisfiable. (We were writing the right thing to disk if it succeeded,
at least.)
For 0.9.0, we changed the structure of documents in the
ClientVersions collection. So now we just throw in a single
dummy document in the old format, triggering a reload.
Fixes#2447
For 0.9.0, we changed the structure of documents in the
ClientVersions collection. So now we just throw in a single
dummy document in the old format, triggering a reload.
Fixes#2447
Drop the "at-least" constraint type entirely. It was not user-accessible
and was only used in the form ">=0.0.0" to represent a constraint with
no version constraint at all. This type of constraint is now called
"any-reasonable".
The definition of "any-reasonable" is:
- Any version that is not a pre-release (has no dash)
- Or a pre-release version that is explicitly mentioned in a TOP-LEVEL
constraint passed to the constraint solver
For example, constraints from .meteor/packages, constraints from the
release, and constraints from the command line of "meteor add" end up
being top-level.
Why only top-level-constrained pre-release versions, and not versions we
find explicitly desired by some other desired version while walking the
graph?
The constraint solver assumes that adding a constraint to the resolver
state can't make previously impossible choices now possible. If
pre-releases mentioned anywhere worked, then applying the constraints
"any reasonable" followed by "1.2.3-rc1" would result in "1.2.3-rc1"
ruled first impossible and then possible again. That's no good, so we
have to fix the meaning based on something at the start. (We could try
to apply our prerelease-avoidance tactics solely in the cost functions,
but then it becomes a much less strict rule.)
At the very least, this change should allow you to run meteor on a
preview branch like cordova-hcp without getting a conflict between the
prerelease package on the branch/release and the lack of an explicit
constraint in .meteor/packages on that package, because we are
reintepreting the .meteor/packages constraint as meaning "anything
reasonable" and the in-the-release version counts as reasonable.
The root of the problem David Greenspan tried to fix was that
__meteor_runtime_config__.autoupdateVersion was incorrectly 'unknown'
when running tests (due to packages/test-in-browser/autoupdate.js being
handled wrong by autoupdate_server.js). Turns out the right solution is
to ensure the version is known, not to avoid reloading when the version
is unknown.
