Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.5.3 #9266

merged 38 commits into from Nov 5, 2017

Release 1.5.3 #9266

merged 38 commits into from Nov 5, 2017


Copy link

@abernix abernix commented Oct 28, 2017

This will be a simple follow-up release to Meteor 1.5.2, with the most important inclusion being Node v4.8.5 which includes a Node.js security update as explained in the v4.8.5 release blog. Due to the timing of the Node.js security release, the fixes for our garbage collection patch, which fixed a recurring segmentation fault which manifested itself during Meteor development, were pushed to Node v4.8.6 (which will likely be the last v4 Node.js release). Therefore, this version of Meteor will still ship a version of Node which includes our fix until we can move back to the official v4.8.x releases.

A change to the import scanner is also being included to address the problem in #9182, which was fixed by #9187 and some follow-up commits. As well as a change which should reduce the size of the dev_bundle (which is downloaded for each Meteor upgrade) for Unix builds. Other small fixes may be considered, though the focus should be to get this release out as soon as possible.

For Unix platforms, the first release candidate is already ready to test. Please try it as soon as possible and report any issues here!

meteor update --release 1.5.3-rc.0

Unfortunately, I ran into a bit of an issue publishing the Windows version of that build, and I'll have to finish looking into it next week.

benjamn and others added 18 commits September 29, 2017 18:03
While the actual version included for Unix developers will be our own
build at NODE_VERSION, this is important for the Windows version, since
it is not being rebuilt by our Jenkins at the moment.
By checking and setting this property earlier, we can avoid scanning files
more than once.
Previously, if more than one module in a package tried and failed to
import the same identifier, we would record information about only the
last failed import.

This was good enough for later attempting to resolve the failed import in
other packges or the application's `node_modules` directory (a concept
known as "peer dependencies"), but it sometimes discarded information
about whether the failed imports were dynamic. In particular, if the last
recorded failed import was a dynamic import, it could accidentally render
the entire peer dependency tree dynamic.

Although it's a bit more complicated than what we did before, I believe
the simplest solution is for the ImportScanner to maintain a mapping from
failed identifiers to lists of import information objects, rather than a
single object, so that no information is lost.
The `installPath` property was always essentially an absolute module
identifier that was simply missing the leading '/' character, so this
commit acknowledges that role by renaming the property to `absModuleId`
and adding the leading slash.
Copy link

benjamn commented Oct 28, 2017

We ended up reverting the “Rename installPath property to absModuleId, and make absolute” commit on release-1.6, so I think we should do that here as well, or maybe just rebase it out and force push?

Copy link

benjamn commented Oct 28, 2017

If we do decide to rebase, I suppose we could squash the typo fix commit into the commit that introduced the typo, too?

Copy link

sirpy commented Oct 29, 2017

i've experienced segmentation faults when running in production, ie running the bundle with "node main.js" (i'm using mup with abrenix:meteord)
switching to running production with "meteor node" instead of the installed node solves the issue and the segmentation faults stopped.

This reverts commit b9f0a54.

Though probably a good idea for the future, this change was not really
necessary for Meteor 1.6, and probably too risky for a release candidate.
These errors are especially harmful because they cause files.rename to
fall back to copying rather than atomically renaming, which is both much
slower and not even remotely atomic.
Using a Symbol ensures compiler plugins can't mark files fake accidentally
(or maliciously) when calling inputFile.addJavaScript(options).
Further explanation / discussion:
#9176 (comment)

Another (complementary) solution to the same problem: #9190
This should hopefully prevent ENOTEMPTY errors on Windows.
A while back, for performance reasons, we disabled yielding for all
files.* operations unless METEOR_DISABLE_FS_FIBERS was set to false.

This was safe for almost all files.* operations, because most of them have
a synchronous fs.*Sync version available.

For a more complicated operation like files.rm_recursive, however, there
is no synchronous or asynchronous counterpart in the fs.* namespace, so
the safety of disabling fibers is not guaranteed.

Lately, files.rm_recursive has become a major source of uncaught ENOTEMPTY
errors on Windows, because rimraf.sync fails with that error, and we don't
give files.rm_recursive_async a chance to delete the directory in a more
persistent, forgiving manner.

The only reason we haven't been falling back to files.rm_recursive_async
is that YIELD_ALLOWED is false by default, so canYield() returns false.

This commit distinguishes between canYield() and mayYield(), and uses
canYield() in files.rm_recursive to determine whether it is technically
safe to yield, regardless of YIELD_ALLOWED.

Anyone who ever asked "Can I go to the bathroom?" in elementary school,
only to be mercilessly rebuked with "I don't know, CAN YOU?" should
understand the difference between these two functions.
This was dangerous because source is often a path relative to the old
target file, whereas files.stat was interpreting source as a path relative
to process.cwd().

Fixes #9203.
Copy link
Contributor Author

abernix commented Oct 31, 2017

Good shout on reverting 4e778b6, @benjamn. In fact, that turned out to be the solution to the Windows publishing problem. I opted to just revert that single commit and not rebase since I had already published 1.5.3-rc.0 (and its associated release/METEOR@1.5.3-rc.0 tag).

Meteor 1.5.3-rc.1 is now published for all its supported platforms (specifically: keep in mind that there will only be a 32-bit Windows build, whereas Meteor 1.6 is now available on Windows in a 64-bit flavor as well).

meteor update --release 1.5.3-rc.1

@benjamn benjamn changed the base branch from master to release- November 2, 2017 15:31
@benjamn benjamn changed the base branch from release- to release-1.5.x November 2, 2017 15:34
@benjamn benjamn closed this Nov 2, 2017
@benjamn benjamn reopened this Nov 2, 2017
This implements a first generation of Windows CI testing.  Presently,
this only runs valuable, hand-picked tests which have been known to work
in the past, and whose failure would indicate a critical problem.

A test which isn't passing doesn't mean that the feature being tested is
not working. For example, the 'create' test fails ostentatiously,
though the 'meteor create' command certainly works in practice. This
points to problems some compatibility problems with the 'self-test'
harness itself, some of which I'm aware of.  Though, it likely will
highlight some legitimate problems which Windows users experience too.

There are a number of additional tests which should be enabled which
likely pass already, and many more which are failing and we should fix.

Additional tests can be added to the scripts/windows/appveyor/test.ps1
file as they've been deemed working.

Altogether, this will take extensive work to achieve the same level of
coverage our Unix test suite enjoy, but we've got to start somewhere!

cc @benjamn
These take precedence over the UI, and I'm not sure the UI is taking
effect at the moment.

We don't need to build branches which start with 'dev-bundle-' since
those dev bundles won't be built yet when the tests are kicked off.
Though it was thought to be reliable when running through 'self-test' on
Windows, it's yet to be seen how reliable.

The worst thing that could come of adding Windows testing would be that
we have test failures again after such a string of green checkmarks and

Also, reordered.
Even with $ErrorActionPreference, PowerShell won't automatically fail
when an external command fails with an error code.  This explicitly
checks those exit codes and throws an error when that occurs.

Hopefully prevents false successes like that shown in this AppVeyor
test run:
[ci skip] (Hopefully.)
Copy link
Contributor Author

abernix commented Nov 5, 2017

For those still on the 1.5.x-series of Meteor, Meteor 1.5.3 has been officially released! The changelog is available on master's, in addition to the 1.5.3 docs changelog.

Note that since Meteor 1.6 is the most recent, it will be necessary to use the --release argument to stay on the 1.5.x series since meteor update by itself will jump straight to 1.6. Within an existing application, this can be done by running:

meteor update --release 1.5.3

@abernix abernix mentioned this pull request Nov 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

3 participants