Share

Reposted From Medium

Earlier this year, I was proud to help corral and kick off the Node.js LTS Working Group. After a number of iterations, we have now formalized a long term support (LTS) strategy that takes into account both historical and future releases of Node.js. Having such a strategy in place is an inevitable step for any significant open source project that enjoys widespread adoption by enterprise customers and other professional organizations.

The point of establishing an LTS plan for Node is to build on top of an existing stable release cycle by delivering new new versions on a predictable schedule that have a clearly defined extended support lifecycle. While this may seem at odds with the open source tradition of “release early, release often” it is an essential requirement for enterprise application development and operations teams. It also affects companies like ours that provide professional support for Node.js (see our recent N|Support announcement).

Creating an LTS strategy that will endure the test of time requires some key considerations. What code are LTS releases based on? When and how often will we have new LTS branches? How long are they supported? What does that support look like? What kind of changes are are likely to occur during the lifespan of an LTS branch? How are the releases managed and by whom?

The Node.js LTS Working Group already has answers to most of these questions and continues to refine the strategy as it receives feedback from the community and likely users of LTS releases.

Bear with me on some of the details, things are moving and changing rapidly, but the current plan is as follows:

What

The first new LTS release will emerge from the new converged Node.js codebase. This code is based on the latest io.js code with additional features added that are currently not included in io.js, but are included in Node.js v0.12. The largest of these being proper support for the Intl object.

The new version of Node that emerges from this converged work will have a major version number of one above the highest io.js release at that time. The current plan calls for a new release in August and io.js is likely to have a v3 out by then so the next version — that will be formally called Node.js — will probably be Node.js v4.0.0.

Because of the convergence work — and the fact that there isn’t as much difference between io.js and Node.js v0.12 as is sometimes suggested — it’s likely that little, if any, modifications will be required to run existing applications on the new version. The biggest difference will be found under the hood, both in the changing performance profile due to shifts in the way V8 optimizes JavaScript, and at the native add-on layer of Node and V8. It’s the add-on compatibility story that’s likely to be the source of most of the pain that will come from upgrading, but I’ll leave that for another post!

When

Once we have a new Node.js from the converged work and the streams have been crossed, the current plan is targeting October for the first LTS release, making October the LTS release month every year.

In the period between the release of the new Node and the first LTS we will see some evolution in the project, it will follow semver and we may see both patch version increments and minor version increments, but not major version increments (i.e. no intentional breaking changes). Major version increments will happen occasionally for regular stable releases, likely on a predictable cycle (the current plan for stable releases involves major version increments every six months), but not before the first LTS release!

Once we reach October, the LTS Working Group will take over responsibility for the stable release branch, and further releases with the current major version number will officially be LTS releases.

For example: if we see enough work being released from Node.js v4 after August — to bring us to a hypothetical v4.1.3 by October —  the first LTS release will be v4.1.4 when the LTS Working Group takes over. For the life of that first LTS release it will always have a major version number of 4, most likely with ever increasing patch version numbers: v4.1.5, v4.1.6, etc. (see below).

Fun fact: LTS releases will also come with codenames to further help differentiate them. Stay tuned for news on that.

How Often

We will see new major LTS versions once every 12 months. Within each major LTS version there will be a number of incremental releases, mostly confined to patch version number increments with the possibility of incrementing the minor version number if absolutely required for bug fixes.

While the schedule of new major LTS versions will be fixed to a 12 month cycle, the schedule of incremental releases within each of these will be driven by the the availability of bug fixes, security fixes and other small but important changes. The focus will be on stability, but stability also includes minimizing the number of known bugs and staying on top of security concerns as they arise.

How Long

Even though new LTS releases will be appearing every 12 months, each of these major versions will be supported for 18 months thereafter. Then, for an additional 12 months, the branch will go into maintenance — where only severe bugs and security problems will be addressed. The difference between LTS and maintenance is in the severity threshold for fixes.

This obviously means that at any point in time, there will be multiple active LTS and maintenance lines. This is to allow a smooth migration path and enough padding time for complex deployments requiring careful management.

Node.js v0.10 and v0.12 are special cases in the LTS plan. v0.10 will go directly into maintenance in October, lasting for 12 months. v0.12 will have an initial LTS period of 6 months starting from October, followed by the requisite 12 months maintenance. io.js releases will not have official LTS or maintenance support.

Of course, one of the stand-out challenges for the LTS Working Group will be in supporting versions of V8 that have been long forgotten by the Chromium team. This won’t be an easy task and we will have to find ways of giving it the attention that is needed to ensure stability and security. But we’re up to the challenge!

Who

The Node.js LTS Working Group includes representatives from IBM, NodeSource, Joyent and StrongLoop. This group will evolve over time, aligned around a shared interest in serving users of Node who have to consider a long-view in their deployments.

An Essential Step

Our mission at NodeSource is to ready Node.js for the enterprise — and ready the enterprise for Node.js.

Creating a predictable release cycle with clear-cut migration paths and a sound support mechanism is key to this mission. For this reason, supporting a solid LTS process for Node is a high priority for NodeSource, particularly for the N|Support team.

Considering the major milestones for Node.js — large-scale production deployments, the fastest growing applications platform, the world’s largest package ecosystem — a predictable release and support mechanism for the enterprise is an essential step.

Read the LTS plan. To provide feedback on how the current LTS strategy may impact your organization, either create an issue on the LTS repository or contact me directly to have your comments passed on: rvagg@nodesource.com.