Node.js 8.0.0 has been delayed and will ship on or around May 30th

This post is brought to you by Myles Borins who is a @nodejs ctc member / developer advocate for @googlecloud. Now with that background, let’s dive into the “why” of the delay around Node.js 8.0.0.

Why? The short version

We want to give ourselves the option to ship the Node.js 8.x release line with the TurboFan + Ignition pipeline, which will become the default in V8 5.9. This would allow our next LTS release line to run on a more modern compiler + jit pipeline, making backporting easier and giving us a longer support contract from the V8 team.

Why? The longer version

A few weeks ago I had a discussion with James Snell about the 8.0.0 release where we discovered a very unfortunate oversight. The project had decided to keep 8.0.0 on the Crankshaft and full-codegen pipeline after various meetings with the V8 team. We would land a version of V8 with the TurboFan + Ignition enable into Node.js 9.0.0. There were two primary reasons for this decision:

  1. Give the V8 team time to improve performance and bugs in the pipeline
  2. Offer a known and stable experience for an LTS release line

The oversight was the complication this would create for LTS. With V8 5.9 schedule to release in early June, Node.js 8.x would have less than two months of support from the V8 team for the old pipeline. The team has projected large amounts of churn in the pipeline between V8 5.9 and 6.0, which would make backporting to V8 5.7 or 5.8 fairly difficult. We would find ourselves in a position where we would be shipping an unsupported version of V8 for close to 3 years. This was the first problem.

Further complicating matters was the fact that a nontrivial part of the Node.js code base had been tuned to be optimized by Crankshaft. This code has been eloquently referred to as Crankscript. If we were to wait until 9.0.0 to begin refactoring our Crankscript we would experience a fairly large delta between 8.x and 9.x very early in the life cycle of Carbon LTS.

There was also a security concern. The Chrome team does constant security audits on V8. If the project were to move forward on the old pipeline we would essentially be flying blind for 3 years.

Some context

The Argon LTS stream of Node.js (4.x) only recently went into Maintenance, which has a year of support. We are still backporting code from 7.x with relatively few conflicts. This is due to the project being very careful about introducing churn. Comparatively, if 8.x and 9.x drifted fairly quickly, backporting could prove difficult in the first few months. It would be extremely hard to imagine that code from 11.x would be able to cleanly backport to 8.x. Even worse, any changes that affected performance would likely need to be manually tested to ensure that the performance profile was consistent.

What happened next..

After the conversation I had with James, I immediately started a chat with the V8 team to get their pulse on what we should do. Working with the team we put together three different plans for Node.js and V8:

  1. Do nothing (ship with V8 5.7)
  2. Ship on time with a version of V8 5.8 that is ABI compatible to 5.9
  3. Delay the release to allow us to ship with a version of V8 5.8 that is ABI compatible to 6.0

The CTC voted in favor of delaying the release to give us the most options moving forward with the 8.x release line.

So what is next?

We are currently testing the performance of the new pipeline and the results are promising. The V8 team is preparing special versions of 5.8 that are ABI compatible to 6.0. This will allow us to upgrade to the new pipeline as a non-breaking change, and maximize our ability to backport code to the LTS release. The 8.0.0 release will come out on or around May 30th, and unless we see any serious problems we will be able to introduce the new pipeline in early June. The LTS release date remains in October, unaffected by this delay.

Questions?

There is a lot going on here. If you have any questions at all please reach out to me on Twitter.