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

Release 1.5.3 #9266

merged 38 commits into from Nov 5, 2017

Conversation

@abernix
Copy link
Member

@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 Sep 29, 2017
Release 1.5.2.2
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.
Fixes #9182.
Introduced by 3faee05.

cc @cpury @JanMP
@benjamn
Copy link
Member

@benjamn 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
Copy link
Member

@benjamn 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
Copy link

@sirpy 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 9 commits Oct 8, 2017
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.
benjamn and others added 4 commits Oct 16, 2017
Commit 86ec7eb broke tests because we
rely on symlinks even when the symlink option is false.
@abernix
Copy link
Member Author

@abernix 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 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 7 commits Oct 17, 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
confidence.

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: https://goo.gl/xxRsF9.
[ci skip] (Hopefully.)
@abernix abernix merged commit 0191e86 into release-1.5.x Nov 5, 2017
2 checks passed
2 checks passed
@apollo-cla
CLA Author has signed the Meteor CLA.
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@abernix
Copy link
Member Author

@abernix 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 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
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants