Share

Since the formation of the Node.js Foundation, the Node.js project has aimed at moving forward while at the same time providing a stable platform for those that are building businesses and need a reliable foundation.

The key way that this has manifested itself is through the Node.js release process, including the Current release line and the LTS release lines.

I've consistently heard from individuals that this can get a bit confusing, and that there's not enough guidance online to be able to fully understand context around the Node.js release lines and why, when, and how they should be used.

Defining Key Node.js Versioning Terminology

There is some key terminology that can get confusing when discussing Node.js releases. Let's dig into some of these terms to get you the context you need:

General Versioning Terminology

• Release Line: A release line is defined as any major version of Node.js. For example, Node.js 6, Node.js 7, Node.js 8, Node.js 9, and so on are all release lines.
• SemVer: SemVer stands for Semantic Versioning, and is the versioning mechanism that both the Node.js releases and the majority of the Node.js ecosystem use for versioning.
  • Major Release: Major Releases are for incompatible API changes, from version to version. Major releases can also include changes that would normally be included as Minor or Patch releases.
  • Minor Release: Minor Releases include backward compatible functionality changes. Minor releases can also include changes that would normally be included as Patch releases.
  • Patch Release: Patch releases include non-breaking bug fixes and security patches.

Release Terminology

• Current: Current is a term used to refer to the most recent Node.js release line (yes, that's singular) that will be supported and open to non-trivial changes until the next major release.
• LTS: LTS is an acronym for Long-Term Support, and is applied to release lines (yes, that's plural) that will be supported and maintained by the Node.js project for an extended period of time.
  • Active: An Active LTS release line is one that is being actively maintained and upgraded, including backporting newer non-breaking features, functionality, and improvements, addressing bugs, and patching security vulnerabilities.
  • Maintenance: A Maintenance LTS release line is a Node.js LTS release line that's nearing End of Life (EOL) and will only receive bug fixes and security patches for a short window of time.
• EOL: EOL is an acronym for End of Life. Node.js versions that are EOL are no longer maintained, and will not be patched with fixes for bugs or known security vulnerabilities.
• Cutting/Shipping: Cutting and shipping are both terms used to refer to the actual release of any given version (major, minor, or patch) of Node.js. These terms aren't specific to Node.js but are used relatively often by the Node.js contributor base.

The Node.js Release Lifecycle

That's a lot of context around terminology, especially for release lines. It can all seem very confusing if you're trying to understand purely from reading it. Fear not, though! To help you understand this a bit better, let's look at how this process works for a single release line, and is then applied to multiple release lines over time.

Even-numbered vs. Odd-numbered Node.js Releases

There's one quirk to how Node.js does releases: even-numbered releases–like Node.js 8, Node.js 10, Node.js 12, and so on–will become LTS. Odd-numbered releases–like Node.js 7, Node.js 9, Node.js 11, and so on–will go EOL as soon as the next SemVer release line ships. So, you can effectively equate even-numbered releases with LTS release lines, and odd-numbered releases with non-LTS release lines.

The Node.js project ships the release lines like this as a way to introduce SemVer Major changes on a consistent, predictable, and regular basis. This helps the project both get end-users feedback around the impact on various aspects of the project and notice if any issues arise within the broader ecosystem itself so they can be addressed before those changes go into an LTS release line.

How the Node.js Release Lifecycle is Applied to an LTS Release Line

For any given LTS release line, you can expect a relatively consistent release lifecycle. This includes progressing through the Current, Active LTS, Maintenance LTS, and EOL stages.

This process occurs over three years:

• The Current phase of an even-numbered release line lasts for 6 months, from April to October.
• Once that release line becomes in October, it will be an Active LTS release line for 18 months.
• Once the Active LTS period is over, a release line move into Maintenance LTS for 12 months.
• Once those 12 months are up, the release line will go End of Life (EOL) and will no longer be supported.

While this is the stated process of the project, it's worth noting that the collaborators can indeed vary these dates if required. This would and should happen only to ensure stability and reliability of Node.js and its dependencies. One example of this is the Node.js 8 LTS which will have a three-month early end date because of OpenSSL's LTS cycle for 1.0.x.

How the Node.js Release Lifecycle is Applied Over Time

As the release lifecycle is applied to more and more release lines over time, the project begins to have layered support for multiple LTS versions. This is evident when you look at a timeline that displays multiple LTS releases at different stages of their lifecycle:

This layering of different stages of the LTS cycle enables users of Node.js of all kinds to tweak their internal upgrade process to something that suits their specific use cases. For indie developers, open-source projects, and startups, immediate upgrades can happen every six months. For devices that can't often upgrade (like IoT devices) and enterprise users with a slow upgrade cycle, the versions will live on long enough to be reliable and supported while also providing a clean upgrade path.

Which Versions of Node.js Should You Actually Use?

The honest answer: It depends.

If you're shipping an application or API to production, you should probably err on the side of caution and aim for the latest LTS. If you're developing a side project, you can go ahead and use the Current release line. If you're building tooling that's meant to be super helpful to a bunch of developers, you should probably try to support a range of versions.

There are options, and that's by design. Node.js succeeded because of its ease of use for such a wide range of developers. One of the most important things that happened when io.js and Node.js re-joined was the creation of the LTS process, which helps ensure that Node.js is a stable and reliable platform for a particular set of use cases.

That said, as individual developers the ease of use that Node.js initially provided still exists and will always be maintained going forward. As such, there's no one true and righteous path to follow with which version of Node.js to use. Instead, every organization, every team, and every individual needs to weigh the benefits and drawbacks of different approaches on a case by case basis to best suit the interests of people and projects working with Node.js effectively.

One More Thing...

If you're interested in the Node.js community and learning how Node.js works, you should definitely check out some of our recent posts–you may be interested in checking out How You Can Start Contributing to Node.js Today and Node.js 10: The First Week .

Beyond that, if you want to keep up to date on the Node.js community and what's happening across the ecosystem, you should be sure to check out @NodeSource on Twitter. We try to spread the word as far and wide as possible about the awesome things that are always happening in the community.