By choosing names like Template.registerHelper(…) and Template.instance() (instead of Blaze), we can separate the “Templates” section and the “Blaze” section of the docs.
(The test doesn’t really cover the case we encountered in iron-layout.)
It’s normal to end up calling Blaze.remove on an already-destroyed View, or a View that is not attached directly the DOM but has a parentRange (it’s just that it takes a situation like iron-layout to actually have a pointer to such a View in your code).
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.
There was a rare race condition where SIGUSR2 can fire before the
server starts listening, causing some functions to fail. We added
a future to the synchronous queue to ensure that SIGUSR2 calls
are queued to run after onListen.
There was a rare race condition where SIGUSR2 can fire before the
server starts listening, causing some functions to fail. We added
a future to the synchronous queue to ensure that SIGUSR2 calls
are queued to run after onListen.
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.
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.
