31 comments

[ 0.22 ms ] story [ 240 ms ] thread
This is a nice release.

I've always been confused about V8 versioning. Breaking changes appear to come all the time in minor versions.

And there's this note from the release:

> Note: The version number 5.0 does not carry semantic significance or mark a major release (as opposed to a minor release).

So what does it mark? Why 5.0 at all then?

They changed their versioning process to align with Chrome. Chrome 50 == v8 5.0, Chrome 51 == v8 5.1, etc.
Correct.

Major versions make more sense when you create a release based on the content. V8 is creating its releases based on time (~6 week cadence). So a 'major' version is nothing special anymore. In 4.9 we greatly expanded our ES2015 support which was huge but only incremented the minor version because of the same reason.

Disclaimer: I work on the V8 team.

If you're going to use meaningless version numbers, then it would be better if you used something that didn't imply otherwise. Chrome 50 carries exactly the right connotation, IMO.
Why not date-based version numbers, then, or as bryanlarsen stated, something obviously meaningless, like the Chrome/FF numbers?

Edit: By the way, sorry to derail the conversation. You guys are doing great work! I'm always excited about V8 updates because they generally mean great perf/feature improvements to both the most popular browsers and my runtime of choice, NodeJS.

The reason is simply 'legacy'. Maybe we will change our version numbers to something without major.minor versions.
Maybe this is a stupid question... But why not straight up copy Chrome and jump up to v50 instead of v5.0?
Perhaps they want to align with Node.js version numbering?
It's more likely the other way around; Node runs on V8, not the other way around.
How does nodejs sync with V8 releases? ECMA-version, V8-version, Node-version, Javascript-version, browser-version with different features support, it's quite a bit.
Node.js Stable tries to follow the V8 version from latest stable Chrome quite closely (i.e. soon after the corresponding Chrome release), but occasionally a V8 version may be skipped, e.g. if it has problematic API changes.

Node.js LTS branches stay on a fixed V8 version.

we just managed to get plv8 tracking against the same v8 versions as node (4.4-4.10).

v8 moves very quickly, and even the redhat/debian package maintainers are still distributing 3.14.

Optimisations for ES6 features is great!

Any idea how V8 releases relate to Node (especially now post-io.js)? When could we see these improvements on the server?

Node.js is easy to compile from sources. Basically when https://github.com/nodejs/node/pull/5592 gets merged, all that is needed is

git clone git@github.com:nodejs/node.git; cd node ; git checkout vee-eight-5.0; ./configure; make; make install

to start experimenting.

> Any idea how V8 releases relate to Node (especially now post-io.js)? When could we see these improvements on the server?

April and October are the planned release months for a new major node version AFAIK. The April releases then become LTS releases in October. October releases don't become LTS.

Presumably new major node versions will be cut from the latest stable (or perhaps stable - 1, depending on timing) V8 release.

Might be wrong about this, so I'm open to correction.

Surely I'm not the only one asking "what is this/should I care?"

(three clicks later...) V8 is a javascript engine that supports web assembly.

To give you more context, it is not just "a" javascript engine. It is the engine behind node.jj, Google Chrome, and others!
V8 is the js engine. The one that is so fast because it compiles in JIT, the one that powers Chrome and Node.js, the one that enabled a full range of let's-build-a-full-app-in-a-browser apps.

Also for the worse: the one that lets us include 10Mb of js in a browser.

>The one that is so fast because it compiles in JIT

That's true for all modern JS engines (JavaScriptCore, Edge, SpiderMonkey, v8) and has been for several years (almost a decade).

But only after V8; before that, JS performance had no priority in browsers.
Nope.

In fact Mozilla was somewhat earlier to come up with their JIT-ed JS engine, then Google (v8), then Apple (JSC), but all went live with an insignificant time difference between them (all within a few months in 2008).

(Insignificant since the respective companies have already been working on them simultaneously for years -- so going live was mostly based on who wrapped up first, bugs be damned, not on some unique innovation that others later copied).

Yes, you are probably the only one.
This may be true, but as an embedded developer my world is quite different from the fullstack work many of the rest of audience here.

I could have phrased it more delicately, but I assure you I wasn't being a smart-alek. There is a steady stream of new/unfamiliar tools discussed here and I find that I'm frequently clicking just to find out what it's all about.

I'm sure the problem in your case is that apparently the blog is hosted off-site from the v8 project's site; you need to go to the homepage (v8project.blogspot.com) and find a link on the right side to get to https://github.com/v8/v8/wiki, which has a short introduction to what v8 is. It's a bit underwhelming, really.
Anyone know the V8 version that they are targeting for node.js 6?

There are some sweet features in ES6 V8 4.9 that I would love to start using including optional arguments and array based destructuring.