Upgrade to V8 5.0.71.32 in master by ofrobots · Pull Request #6111 · nodejs/node (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation18 Commits2 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

ofrobots

Checklist
Affected core subsystem(s)

deps

Description of change

This PR is a rebase of vee-eight-5.0 (+ latest V8 5.0 lkgr) to master.

Normally we wait for V8 version to launch in Chrome stable before landing it onto master. Given that we are planning to start releasing RCs for Node v6 next week, it would be convenient to land V8 5.0 onto master sooner than normal. I expect that V8 5.0 will hit stable within the next couple of weeks.

Ref: #5945, #5766.
R=@nodejs/v8
/cc @nodejs/ctc
CI: https://ci.nodejs.org/job/node-test-pull-request/2217/ (5.0.71.31)
CI: https://ci.nodejs.org/job/node-test-pull-request/2258/

@jasnell

@nodejs/ctc ... I would like to get this in before cutting the first release candidate for v6 on Monday afternoon but I'd like to get sign off first. If necessary, I can cut the release candidate as a branch off the vee-eight-5.0 branch rebased on the current master but, in general, I think it would be better to go directly off master.

@Fishrock123

I think it would be safest to make the first RC off a PR/branch like this.

@Fishrock123

@nodejs/benchmarking Could you run a special run off a branch for comparison, but not actually add to the usual graphs on the website?

@Fishrock123

@rvagg

Since we have no guarantee that Chromium 50 will go stable in time I think this presents a risk for our schedule and I'd rather not lock it in like this. If 50 doesn't get out during this month then we're going to have to ship with 4.9 and update to 5.0 later on. Locking ourselves in to Chromium's release schedule would be irresponsible when we've put so much work in to communicating our release schedule. So my suggestion is that if you really want to include 5.0 in RC builds then do it off the vee-eight-5.0 branch.

@jasnell

OK. Fortunately and unfortunately I'm behind schedule today so I won't be cutting the v6 RC1 until later this evening or tomorrow (likely tomorrow).

@bricss

Chrome team have bumped canary branch to v52 it means that they should release v50 to stable in next few weeks, I hope so 🐙

@ofrobots ofrobots changed the titleUpgrade to V8 5.0.71.31 in master Upgrade to V8 5.0.71.32 in master

Apr 13, 2016

@ofrobots

@Fishrock123

@ofrobots that means this version is the stable branch? (i.e. 5.0.71.x)

@ofrobots

Fishrock123, geowarin, dlmanning, ChALkeR, bricss, mgol, krnlde, abenhamdine, flaki, lin7sh, and ubaltaci reacted with hooray emoji

@santigimeno

This is the first time I've seen this test failure in SmartOS:
https://ci.nodejs.org/job/node-test-commit-smartos/nodes=smartos14-64/2065/

# 
# assert.js:90
#   throw new assert.AssertionError({
#   ^
# AssertionError: 'This is a unicode text: سلام' == ''
#     at process.<anonymous> (/home/iojs/build/workspace/node-test-commit-smartos/nodes/smartos14-64/test/parallel/test-http-default-encoding.js:36:10)
#     at emitOne (events.js:95:20)
#     at process.emit (events.js:182:7)
#     at process.exit (internal/process.js:79:15)
#     at ClientRequest.<anonymous> (/home/iojs/build/workspace/node-test-commit-smartos/nodes/smartos14-64/test/parallel/test-http-default-encoding.js:31:13)
#     at emitOne (events.js:90:13)
#     at ClientRequest.emit (events.js:182:7)
#     at Socket.socketErrorListener (_http_client.js:306:9)
#     at emitOne (events.js:90:13)
#     at Socket.emit (events.js:182:7)
# connect ECONNREFUSED 127.0.0.1:12346

I don't know if it is related or not though.

@ofrobots

@targos

@ofrobots

@targos

@bnoordhuis

Rubber-stamp LGTM. Looks like the ARM failure is a flake; the test uses process.on('uncaughtException') - huge red flag. Are you going to squash the two upgrade commits?

@indutny

@ofrobots

@targos @ofrobots

V8 5.0 introduced a small modification for the unexpected end of input error.

PR-URL: nodejs#5945 Reviewed-By: bnoordhuis - Ben Noordhuis info@bnoordhuis.nl Reviewed-By: indutny - Fedor Indutny fedor.indutny@gmail.com

@ofrobots

@MylesBorins MylesBorins added the semver-major

PRs that contain breaking changes and should be released in the next major version.

label

Apr 19, 2016

jasnell added a commit that referenced this pull request

Apr 26, 2016

@jasnell

The following significant (semver-major) changes have been made since the previous Node v5.0.0 release.

jasnell added a commit that referenced this pull request

Apr 26, 2016

@jasnell

The following significant (semver-major) changes have been made since the previous Node v5.0.0 release.

jasnell pushed a commit that referenced this pull request

Apr 26, 2016

@ofrobots @jasnell

jasnell added a commit that referenced this pull request

Apr 26, 2016

@jasnell

The following significant (semver-major) changes have been made since the previous Node v5.0.0 release.

jasnell added a commit that referenced this pull request

Apr 26, 2016

@jasnell

The following significant (semver-major) changes have been made since the previous Node v5.0.0 release.

jasnell added a commit that referenced this pull request

Apr 26, 2016

@jasnell

The following significant (semver-major) changes have been made since the previous Node v5.0.0 release.

Labels

semver-major

PRs that contain breaking changes and should be released in the next major version.

v8 engine

Issues and PRs related to the V8 dependency.