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

Chrome 43 released; time for V8 4.3! #1735

Closed
domenic opened this issue May 19, 2015 · 15 comments
Closed

Chrome 43 released; time for V8 4.3! #1735

domenic opened this issue May 19, 2015 · 15 comments
Labels
v8 engine Issues and PRs related to the V8 dependency.

Comments

@domenic
Copy link
Contributor

domenic commented May 19, 2015

http://googlechromereleases.blogspot.com/2015/05/stable-channel-update_19.html

@Fishrock123
Copy link
Contributor

Good grief it would be nice to do these in minors. Maybe we should just do every other or something.

@domenic
Copy link
Contributor Author

domenic commented May 19, 2015

This is just our bad because we were 4 weeks into a 6-week cycle before we finished up with 4.2.

@mscdex mscdex added the v8 engine Issues and PRs related to the V8 dependency. label May 19, 2015
@Fishrock123
Copy link
Contributor

Honestly I don't really like having our major schedule dictated by a dependency.

@rvagg
Copy link
Member

rvagg commented May 19, 2015

"io.js is moving too fast" is something I'm hearing a bit but I honestly believe this is:

  1. a new reality people will need to get used to; and
  2. a reinforcement of our need to dig in to LTS to provide a sense of stability

I'm fine with bumping major more frequently but would prefer it to be tied to actual "breaking" changes and we need to be sure that V8 upgrades do that.

@chrisdickinson how's next going?

@Fishrock123
Copy link
Contributor

I'm fine with moving fast, but this project doesn't quite work like v8 / chrome does where everything is in-company.

And again, we should be able to cut majors when we feel it is good, not when a dependancy releases again for the billionth time.

I guess at least we won't have to LTS 2.x

@mscdex
Copy link
Contributor

mscdex commented May 19, 2015

Also something to think about: if node/io/whatever eventually adopts a multi-JS backend feature (e.g. with Chakra, Spidermonkey, etc.), would we still align with v8 releases?

@domenic
Copy link
Contributor Author

domenic commented May 19, 2015

@mscdex If we do that, presumably we'll have figured out a way to avoid breaking ABI on every V8 release via our amazing pie-in-the-sky multi-VM wrapper, so, we won't need to do major releases in that case.

@imyller
Copy link
Member

imyller commented May 19, 2015

@kkoopa is nan ready for this yet?
If not, this is going to hit native module compatibility even harder than 2.x.x did.

@kkoopa
Copy link

kkoopa commented May 19, 2015

It is, but won't be released until the other loose ends are tied.

On May 19, 2015 8:28:54 PM EEST, Ilkka Myller notifications@github.com wrote:

@kkoopa is nan ready for this yet?
If not, this is going to hit native module compatibility even harder
than 2.x.x did.


Reply to this email directly or view it on GitHub:
#1735 (comment)

@Fishrock123
Copy link
Contributor

Here's a CI for the next branch: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/694/

@chrisdickinson
Copy link
Contributor

@rvagg The vm problem persists in next – I'm not sure I have the expertise necessary to diagnose what's going wrong exactly. Perhaps @bnoordhuis or @domenic has made progress on this?

@Fishrock123 As @domenic notes, we released v2 pretty far into the v8 cycle, so we're paying the proverbial piper by having an abbreviated v2 line. We were also figuring out how we wanted to arrange branches and juggling a few other issues at the time – as we get better at hitting cadence with v8, I think the major version bumps will be a bit more natural.

That said, semver is for computers, LTS lines are for humans. We shouldn't worry about bumping one of those arbitrary integers – and we should definitely distance ourselves from editorializing which numbers feel good to bump, and when. We should figure out how to properly label and recommend particular subsets of those integers to humans.

@Fishrock123
Copy link
Contributor

Fair enough, @domenic said earlier in IRC he'd try to look into it.

@bricss
Copy link

bricss commented May 20, 2015

Just bump v2.1.0 and roll out release :)

@rvagg
Copy link
Member

rvagg commented Jun 3, 2015

leaving on tsc-agenda, there's probably more to discuss here

@Fishrock123
Copy link
Contributor

I'm pretty sure we are now PR-ing 4.4 into next. Closing.

ronag added a commit to nxtedition/node that referenced this issue Apr 27, 2018
Fixes: nodejs#20102
Fixes: nodejs#20101
Fixes: nodejs#1735

- Response should always emit close.
- Response should always emit aborted if aborted.
- Response should always emit close after request has emitted close.
trivikr pushed a commit that referenced this issue May 14, 2018
Fixes: #20102
Fixes: #20101
Fixes: #1735

- Response should always emit close.
- Response should always emit aborted if aborted.
- Response should always emit close after request has emitted close.

PR-URL: #20075
Fixes: #17352
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
addaleax pushed a commit that referenced this issue May 14, 2018
Fixes: #20102
Fixes: #20101
Fixes: #1735

- Response should always emit close.
- Response should always emit aborted if aborted.
- Response should always emit close after request has emitted close.

PR-URL: #20075
Fixes: #17352
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v8 engine Issues and PRs related to the V8 dependency.
Projects
None yet
Development

No branches or pull requests

9 participants