The new Node.js Release and LTS plan took effect in 2015 with the release of Node.js v4. While it also takes into account older versions of Node.js, it is easiest to understand when looking forward from v4:

Node.js primarily uses Semantic Versioning ("semver") to identify releases. This versioning scheme uses three numbers, separated by a period ("."). The first of these numbers is the Major version number (we generally refer to this as "semver-major"). Semver dictates that all incremental releases sharing the same Major number shall be backward compatible, with no intentionally breaking changes introduced throughout this series of releases. If you are unfamiliar with Semantic Versioning, please review the documentation available at http://semver.org as Node.js, and the majority of its package ecosystem, make heavy use of this scheme to identify the types of changes introduced in each release.

New semver-major release lines of Node.js are cut from the master development branch every six months. New even-numbered release lines (e.g. v6, v8, v10, etc) are cut in April. New odd-numbered release lines (e.g. v5, v7, v9) are cut in October. These 6-monthly release lines are initially referred to as "Current" and receive most non-breaking changes that occur on the master development branch of Node.js, hence their semver-minor version numbers can increase rapidly during this period.

In October of each year, the even-numbered "Current" release line is transitioned on to the Long Term Support (LTS) plan and begin to be referred to as "LTS". At the same time, a new odd-numbered "Current" release line is created.

Every release line covered by LTS will be actively maintained for an initial period of 18 months from the date it enters LTS coverage; this is "Active LTS". Following those 18 months of active support, the release line will transition into "Maintenance" mode for 12 additional months.

Given this schedule, there will be no more than two "Active LTS" release lines at any given time, overlapping for a maximum period of six months. Users are encouraged to use this overlap to plan a migration path between LTS release lines.

Release lines not covered by LTS (i.e. odd-numbered release lines) receive an additional 2 months of "Maintenance"-style support following their 6 months as "Current" releases.

All release lines covering a single semver-major version number, be it labelled "Current", "Active LTS" or "Maintenance" will:

• Not receive commits labelled "semver-major" except in the special case of critical security fixes (see below). That is, the external API of any release line shall not be intentionally changed in a non-backward-compatible way.
• Receive commits labelled "semver-minor". However, it is expected that release lines that are covered by LTS shall receive a minimal number of these changes in order to maximise stability. Additionally, semver-minor changes will be delayed and grouped as much as is practical in LTS release lines in order to ease the upgrade path for users of that line. Any semver-minor commits proposed for inclusion in an LTS release line will require:
  • sign-off from at least one active member of the LTS Working Group;
  • no objection from any active member of the LTS Working Group
• Receive semver-patch commits, i.e. those not labelled either semver-major or semver-minor as appropriate. Any semver-patch commits proposed for inclusion in an LTS release line will require:
  • sign-off from at least one active member of the LTS Working Group;
  • no objection from any active member of the LTS Working Group

The Node.js JavaScript runtime, V8, is part of the Node.js C++ API. Therefore, changes to the C++ API of V8 have a flow-on effect to the Node.js package ecosystem and must be treated in a similar way to changes to the core of Node.js itself. In general, major versions of V8 (e.g. 5.1, 5.2, 5.3, etc. — note that these are not semver) are considered breaking changes for Node.js users due to the regular changes in the C++ API (application programming interface) and ABI (application binary interface) even if the JavaScript API remains stable.

All new semver-major increments start out with a fresh API and ABI from their x.0.0 release. While the C++ API may change over time according to semver rules (e.g. introducing new features that are backward-compatible—"semver-minor"), the ABI must strictly remain stable over the life of that major version, even as it moves through the various stages ("Current", "Active LTS" and "Maintenance").

Release lines in "Active LTS" and "Maintenance" will be pinned to a single major version of V8 during their lifetime in order to maximise stability. Bug fixes and improvements may be introduced, either by downstreaming, backporting, or by original authorship, according to the same policy for Node.js changes for LTS release lines.

Release lines in "Current" may receive updates to their V8 dependency. This will occur only if it can be done in a way that is not semver-major and does not break the stable ABI of the current major version. This may be achieved by either receiving an ABI-stable update from upstream or by applying floating patches to the dependency to ensure ABI-stability. Implementation details are left up to the Node.js V8 team.

Upgrades to V8 in a "Current" release line should not occur within two months of that release line moving in to "Active LTS". i.e. upgrades to V8 should not occur from August through to the transition of "Current" into LTS in October.

Release lines currently in "Active LTS" will only receive changes that satisfy one or more of the following categories:

1. Bug fixes
2. Security updates
3. Non-semver-major npm updates
4. Relevant documentation updates
5. Certain performance improvements where the risk of breaking existing applications is minimal
6. Changes that introduce large amount of code churn where the risk of breaking existing applications is deemed to be very low and where the change in question may significantly ease the ability to backport future changes due to the reduction in "diff noise"
7. Updates to other dependencies that introduce bug fixes, where members of the LTS Working Group deem such updates very low-risk to stability and security

Release lines currently in "Active LTS" will only receive changes that satisfy one or more of the following categories:

1. Critical bug fixes
2. Critical security fixes
3. Relevant documentation updates
4. Updates to dependencies that introduce critical bug fixes, where members of the LTS Working Group deem such updates very low-risk to stability and security

It is possible that critical security and bug fixes may be labelled "semver-major". Such situations are expected to be rare.

Where it is necessary to introduce such "semver-major" changes into a release line covered by LTS. The changes will result in an increment of the semver-minor version number only. Release notes for releases where these changes have been introduced will clearly state the reason for this situation.

All LTS release lines will be assigned a "codename" drawn from the names of elements on the Periodic Table of Elements. Prior to the transition of a release line to "Active LTS", the LTS Working Group will select a handful of candidate names and submit that short-list to the Node.js Collaborators for a deciding vote.

Every LTS release line has two branches in the Node.js GitHub repository: a release branch and a staging branch. The release branch is used to cut new releases. Only members of the release team should land commits into the release branch. The staging branch is used to land cherry-picked or backported commits from the master (or other) branch that need to be included in a future release of that line.

Example: Node.js v4 has a v4.x branch and a v4.x-staging branch. When commits land in the master branch that must be cherry-picked for a future Node.js v4 release, those commits must be landed into the v4.x-staging branch. When commits are backported (i.e. require non-trivial fixing beyond what Git is able to automatically handle during a cherry-pick) for a future Node.js v4 release, those must come in the form of pull requests opened against the v4.x-staging branch. Commits are only landed in the v4.x branch when a new v4.x release is being prepared.

The officially supported Node.js abstraction layer, NAN, will make all effort to support all currently supported release lines, including "Current", "Active LTS" and "Maintenance". At various times, this will mean supporting at least 4 overlapping supported versions of Node.js: one "Current", two "Active LTS" and one "Maintenance".

• Ben Noordhuis @bnoordhuis
• Jeremiah Senkpiel @Fishrock123
• Wyatt Preul @geek
• James M Snell @jasnell
• João Reis @joaocgreis
• Michael Dawson @mhdawson
• Julien Gilli @misterdjules
• Ali Ijaz Sheikh @ofrobots
• Forrest L Norvell @othiym23
• Rod Vagg @rvagg
• Shigeki Ohtsu @shigeki
• Steven R. Loomis @srl295
• Myles Borins @TheAlphaNerd
• Trevor Norris @trevnorris
• Yunong Xiao @yunong
• Kat Marchán @zkat

Copyright © Node.js Foundation, SPDX-License-Identifier: MIT