Ready to upgrade to V8 4.2?

Counting down the weeks, Chrome 42 should be coming out any day now... That means it's time for V8 4.2!

#1026 was the last discussion. Looks like this will require a 2.x since everyone will need to recompile their addons?

Selflishly, I want this ASAP... Native classes will be huuuge.

+1. Are there any semver major PRs remaining that can go into the next branch?

Are there nightlies or anything for the next branch? If not, some sort of preview release would be nice.

nightlies for next were on my TODO list sorry, I'm obviously overstretched at the moment but I'll try and get to this ASAP cause this is pretty important (and fun)

@rvagg

@rvagg I'd be glad to offer help if you can use it.

@Fishrock123

@iojs/build / @Fishrock123 I've adjusted iojs+release+nightly on Jenkins to take an additional parameter: buildtype which can be either next or next-nightly, it's primarily used to put the nightlies into the right place and set their version name appropriately, it won't do any checks that you are giving it a commit on the next branch though so you still need to use your brain a little when making a nightly.

First nightly built using this has landed here: https://iojs.org/download/next-nightly/ and the rest will go in the same place.

$ cat foo.js

"use strict"

class Dude {
  constructor() {
    this.rnd = Math.random()
  }

  toString() {
    return 'Whoooooooa dude!'
  }
}

class Whoa extends Dude {
  constructor() {
    super()
    console.log(`
      Java me up scotty!
      ${ JSON.stringify(process.versions) }
      ${ JSON.stringify(this.derp('foo', 'bar')) }
      ${ this }
    `)
  }

  derp(...args) {
    return {
        [this.rnd]: 'eh?'
      , [args[0]]: args[1]
    }
  }
}

new Whoa()

$ node --harmony-computed-property-names --harmony-rest-parameters foo.js

      Java me up scotty!
      {"http_parser":"2.3.0","node":"2.0.0-next-nightly2015041138225a7203","v8":"4.2.77.13","uv":"1.4.2","zlib":"1.2.8","ares":"1.10.0-DEV","modules":"44","openssl":"1.0.1m"}
      {"0.6709401244297624":"eh?","foo":"bar"}
      Whoooooooa dude!

Wait, what language is this?

/cc @iojs/evangelism

@othiym23

@othiym23 does npm not like my extended prerelease here?

$ npm i xtend@latest
npm http request GET https://registry.npmjs.org/xtend
npm http 304 https://registry.npmjs.org/xtend
npm WARN engine xtend@4.0.0: wanted: {"node":">=0.4"} (current: {"node":"2.0.0-next-nightly2015041138225a7203","npm":"2.7.1"})
xtend@4.0.0 node_modules/xtend

yay! v8 4.2 shipped class syntax by default.

I thought M43 already branched

@rvagg

@rvagg I think npm sometimes warns for pre-releases.

derp(...args) {

oooo, 4.2 supports spread by default? :D

Edit: is that just --harmony-rest-parameters?

+1

Looking forward 👍

+1 been using classes with the harmony flag for quite a while, code is much cleaner, and it still retains all the prototypal stuff internally, best of both worlds.

What else is delivered along with 4.2? anybody's got a link to the list?

What else is delivered along with 4.2? anybody's got a link to the list?

Classes and object literals are no longer behind a flag.

Rest parameters, computed property names and Unicode escapes ('\u{xxxx}') are new and behind flags. There is a separate flag for Unicode escapes in regular expressions.

Preliminary support for strong mode (tracking bug).

👍 Really looking forward to this!! Can promises be subclassed with the new V8?

@mzgol

@mzgol does chrome that releases every 6 weeks feels unstable to you?
Also, breaking ABI does not nessesairly mean apps breakage, npm rebuild is not so hard to do.
At last, if you can't update every 6 weeks, it is fine, just stay at release that works for you, thought you might miss security patches, but they may also break ABI, so choice is yours.

@YuriSolovyov Chrome doesn't follow semver, its versions aren't even in the semver format (it has 4 numbers). Also, major Chrome releases generally don't break JS APIs because ECMAScript is trying to be as backwards compatible as possible.

Well, if all that's needed is npm rebuild then it may not be worth bumping the major, saving it for changes that will require changes in the code.

The v8 changelog usually lists what has changed. The major thing this time around will be introduction of the maybe monad and making every function return them (but nothing takes them as arguments, making it all rather useless) nodejs/nan#310

With dedicated build servers ABI breaking is kind-of-a-big-deal because the current assumption (coming from node 0.8 and 0.10) is that building on a different node version than running the app is fine. npm rebuild only works if the whole compiler chain is installed on the host - which isn't necessarily true on application hosts. If there's not major bump, it would be great to have some other visible sign for "you can just copy the artifact between hosts". Maybe a wiki page with a list of ABI compatible versions would be enough?

@jkrems You can check NODE_MODULE_VERSION within your modules, though that might not be what you're looking for?

@trevnorris

@trevnorris The setup we have is dedicated build servers creating artifacts that are then just copied to target app hosts. The build host have a compiler chain installed, the app hosts do not. Right now (with node 0.10) it doesn't matter that the patch version of the app host matches the build host. E.g. we can build on 0.10.33 and copy the artifact to a host running 0.10.36.

Arguably it would be better not to have global node versions on the build hosts and always building against an exact match and/or including node in the artifact (e.g. via a container). Just describing our current setup. Not sure how common this kind of flow is.

You should never experience ABI brake in a patch version. The discussion here is whether to increment major or minor.

Sorry, maybe calling out node "0.8 vs. 0.10" was misleading in this regard - for me "0.8 vs. 0.10" was a major bump (according to semver rules). And node patch versions were "minor bumps" from time to time.

My concern here is less about "should ABI bump minor or major" and more about "having a reliable list of what io.js versions are ABI compatible". Given the frequency of minor bumps, assuming that minor bumps break ABI in general seems to be pretty close to assuming that every version breaks ABI. In terms of how helpful it is for reducing maintenance overhead.

Given the frequency of minor bumps, assuming that minor bumps break ABI in general seems to be pretty close to assuming that every version breaks ABI.

I suppose, but it'd basically only be for v8.

I suppose, but it'd basically only be for v8.

In terms of ABI compatibility I don't see how that makes a difference - either the ABI is compatible or it's not. It doesn't matter how many errors there are, it's all or nothing.

If the assumption is that ABI will break every few weeks and this kind of process (having fixed build server versions that might differ from app server versions) won't be supported, then that's fine. Just wanted to bring it up. :) I'm all for getting v8 upgrades out as quickly as possible.

@jkrems good idea. That sounds like a documentation thing. Though probably easier if it lived on the wiki then in official docs?

4.2 has landed in master as per #1506

Navigation Menu

Repository navigation

Ready to upgrade to V8 4.2? #1393

24 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Ready to upgrade to V8 4.2? #1393

Description

Activity

cjihrig commented on Apr 10, 2015

rvagg commented on Apr 11, 2015

cjihrig commented on Apr 11, 2015

rvagg commented on Apr 11, 2015

rvagg commented on Apr 11, 2015

yosuke-furukawa commented on Apr 11, 2015

YurySolovyov commented on Apr 11, 2015

Fishrock123 commented on Apr 11, 2015

bricss commented on Apr 11, 2015

leecade commented on Apr 12, 2015

shekhei commented on Apr 12, 2015

bnoordhuis commented on Apr 12, 2015

hrishikeshs commented on Apr 12, 2015

24 remaining items

YurySolovyov commented on Apr 17, 2015

mgol commented on Apr 17, 2015

mgol commented on Apr 17, 2015

kkoopa commented on Apr 17, 2015

hybrist commented on Apr 20, 2015

trevnorris commented on Apr 20, 2015

hybrist commented on Apr 20, 2015

trevnorris commented on Apr 20, 2015

hybrist commented on Apr 20, 2015

Fishrock123 commented on Apr 20, 2015

hybrist commented on Apr 20, 2015

trevnorris commented on Apr 20, 2015

Fishrock123 commented on Apr 29, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions