As discovered in #8947, creating an app with
meteor create --release 1.4.4.1 new-app
does not actually constrain core packages to have the same minor versions
they had when Meteor 1.4.4.1 was published. Rather (as of Meteor 1.4.3),
the Meteor release only constrains core packages to have versions at least
as recent as the versions they had when the release was published, and to
have the same major version. Any later minor version is fair game.
What we need is a new kind of package version constraint, more like
semver's ~ range operator:
https://www.npmjs.com/package/semver#tilde-ranges-123-12-1
This commit implements that functionality, though it stops short of
supporting all possible semver range syntax.
Backports: b7645a4d1f
These Node and dev bundle version bumps are just to make sure nothing
significant has changed since last time, before we bump the Node version
again for the 1.4.4.5 release.
In a previous commit, I changed
doc = _.extend({}, doc);
to avoid using underscore, thus:
doc = { ...doc };
While this may seem harmless, it broke a few Mongo.Collection tests
because _.extend copies *all* properties, both own and inherited, whereas
object ...spread only copies own properties.
However, the correct way to fix this problem is *not* to revert to the old
behavior, since flattening the inherited properties of a document was
never actually what we wanted. The old behavior was subtly broken, too.
Instead, we need to create a new object with the same prototoype as the
provided document, then shallow-copy the own properties. Any properties or
methods inherited from the original prototype will then be available on
the new object, even though they didn't get copied over.
I've intentionally left some trivial formatting changes in this commit to
remind myself which broken tests were fixed by this change.
1a036553 in 1.4.4.2 expanded on the HTTP error checking added by 30aec9f in
1.4.2. Neither of these changes were aware that discoverGalaxy invokes
httpHelpers.request with json:true, resulting in a `body` that is a parsed JSON
object rather than a string or Buffer. Before 1.4.4.2, this had no consequences
because body.length is undefined and `undefined < 90` is false, but the change
to Buffer.byteLength actually made the condition true.
It's safe to not check length in the JSON case because a truncated JSON object
is not legal JSON (unless the truncation just drops trailing whitespace, in
white case that's OK).
I check for both string and Buffer because some calls to this function pass in
an encoding option. Buffer.byteLength works with both types.
In the ongoing struggle with Circle CI-specific test failures, the
preparatory `meteor --get-ready` has been a consistent point of failure,
before any real tests have the chance to run.
Using a lighter-weight command (meteor --help) that still does most of
what --get-ready did seems worth a try, though it might just defer
memory-intensive work until later, so we'll have to see what happens.
This method appears to be causing large spikes in memory consumption on
Circle CI during the `meteor --get-ready` preparation step, which often
leads to the test process being killed.
Also added a call in IsopackCache#_loadLocalPackage for good measure.
We're now calling requestGarbageCollection pretty frequently when
we run Node with --expose-gc, but that currently only happens during
Circle CI tests, so I don't think we need to implement the improvements
suggested in tools/utils/gc.js, yet.
Previously: 35f488e140, f6df21ff1e
To deal with individual flaky tests, we often just re-run the entire test
suite, which feels like an enormous waste of shared computing resources.
This change automatically re-runs individual failed tests as many as two
more times, and considers the test successful if any of those attempts
succeeds.
cc @abernix @hwillson et al.
This should act as a reminder for those who may be using `smtp://` when
they should be using `smtps://`. Previously, the scheme was implied by
the port number, however this is not the ideal behavior in the same way
that it is unsafe to assume that port 443 is always `https://`.
* Implement CORDOVA_COMPATIBILITY_VERSION_EXCLUDE and CORDOVA_COMPATIBILITY_VERSION_IOS/ANDROID
CORDOVA_COMPATIBILITY_VERSION_IOS or CORDOVA_COMPATIBILITY_VERSION_ANDROID allows to override compatibility version for a specified platform.
CORDOVA_COMPATIBILITY_VERSION_EXCLUDE provides a way of excluding a certain plugin from compatibility version calculation. You can pass several plugin names with ';'. For example: `CORDOVA_COMPATIBILITY_VERSION_EXCLUDE='cordova-plugin-crosswalk-webview;cordova-plugin-device'`
* Changes after review
