Chrome 43 released; time for V8 4.3!

[domenic]

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

[Fishrock123]

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

[domenic]

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

[Fishrock123]

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

[rvagg]

"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]

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]

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]

@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]

@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]

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]

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

[chrisdickinson]

@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]

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