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
merged 38 commits into from Nov 5, 2017

Conversation

Projects
None yet
3 participants
@abernix
Member

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 some commits Sep 29, 2017

Bump $NODE_VERSION to 4.8.5 before rebuilding dev bundle.
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.
Simplify checking/setting file.imported in ImportScanner#_scanFile.
By checking and setting this property earlier, we can avoid scanning files
more than once.
Rename installPath property to absModuleId, and make absolute.
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.
Track all failed imports separately.
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.
@benjamn

This comment has been minimized.

Member

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?

@benjamn

This comment has been minimized.

Member

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?

@sirpy

This comment has been minimized.

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.

benjamn added some commits Oct 8, 2017

Revert "Rename installPath property to absModuleId, and make absolute."
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.
Remove target directory in files.rename to avoid Windows EPERM errors.
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.
Stop using file.imported to mark fake files in the ImportScanner.
Using a Symbol ensures compiler plugins can't mark files fake accidentally
(or maliciously) when calling inputFile.addJavaScript(options).
Use module.watch live bindings to solve #9176.
Further explanation / discussion:
#9176 (comment)

Another (complementary) solution to the same problem: #9190
Use files.rm_recursive_async to implement `meteor reset`.
This should hopefully prevent ENOTEMPTY errors on Windows.
Allow files.rm_recursive to yield whenever possible.
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.
Avoid calling files.stat(source) in symlinkWithOverwrite.
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.

benjamn and others added some commits Oct 16, 2017

Allow Builder#copyDirectory to re-create symlinks again.
Commit 86ec7eb broke tests because we
rely on symlinks even when the symlink option is false.
@abernix

This comment has been minimized.

Member

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

@abernix abernix force-pushed the release-1.5.3 branch from d63df77 to 9efe9e8 Nov 1, 2017

@benjamn benjamn changed the base branch from master to release-1.5.2.2 Nov 2, 2017

@benjamn benjamn changed the base branch from release-1.5.2.2 to release-1.5.x Nov 2, 2017

@benjamn benjamn closed this Nov 2, 2017

@benjamn benjamn reopened this Nov 2, 2017

abernix added some commits Oct 17, 2017

Basic Appveyor testing for Windows.
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
Use YAML config for Appveyor settings, rather than their UI.
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.
Remove problematic Windows test, until it can be researched further.
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
confidence.

Also, reordered.
Throw an error when any external command fails during test preparation.
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: https://goo.gl/xxRsF9.
Tweaks to History.md for 1.5.3.
[ci skip] (Hopefully.)

@abernix abernix merged commit 0191e86 into release-1.5.x Nov 5, 2017

2 checks passed

CLA Author has signed the Meteor CLA.
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@abernix

This comment has been minimized.

Member

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 History.md, 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 referenced this pull request Nov 7, 2017

Merged

Release 1.5.4 #9320

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment