Node.js just told the world it is cutting major releases from two a year to one. The headline framing, that every release now becomes a long-term support (LTS) version, sounds like a gift to developers. The real story is narrower and more self-interested: the Node.js release team was burning out trying to patch security holes across four or five live code branches at once, and this October's release schedule change is how they make that number smaller.
Key takeaways
- Starting this October, Node.js moves from two major releases a year to one, ending the odd/even version split that has existed since the 2015 io.js merger.
- Node.js 26, released in May 2026, enters LTS this October under the old rules; Node.js 27 begins its six-month Alpha phase this October under the new rules, with 27.0.0 shipping in April 2027.
- Every future release gets promoted to LTS, but the 30-month LTS support window is unchanged, so teams that already wait for LTS see almost no practical difference beyond version numbers.
- Teams that rode the twice-a-year Current line for early access to new APIs now wait about twice as long, roughly a year instead of six months, between major versions.
The Node.js Release Schedule Change Is About Headcount, Not Features
According to the Node.js Release Working Group's own announcement, the current schedule is a decade old, dating back to decisions made during the io.js merger "as an educated guess of what enterprises would need." That guess produced a pattern where a new Current release shipped every April and October, one of which (the even-numbered one) was promoted to LTS for 30 months, while the other (the odd-numbered one) quietly died after about six months of life.
The working group's own usage data shows odd releases saw minimal real-world adoption. Most production teams waited for LTS and ignored the odd version entirely. Yet someone still had to backport security fixes into that odd branch for the six months it existed. Multiply that across several overlapping LTS lines and you get the "four or five active lines" the team cites as the real burden. The October 2026 Node.js release schedule change exists to shrink that number, not to hand developers more stable releases than they already had. It is worth noting this runs opposite to what browser vendors just did: Chrome, Edge and Firefox sped up to a two-week release cycle, while Node.js is slowing its major-version cadence down, because the two projects are solving different maintenance problems.
What Actually Changes: One Release, One Path to LTS
Under the new model, every major version follows the same three phases: a six-month Alpha (October to March) for early testing and breaking changes, a six-month Current (April to October) for stabilization, then a 30-month LTS period with security fixes only. Node.js 26, the last release built under the old rules, shipped May 5, 2026 and enters LTS this October, running until October 2027 with end of life in April 2029. Node.js 27, the first release under the new rules, starts Alpha this October, ships as 27.0.0 in April 2027, enters LTS in October 2027, and reaches end of life in April 2030.
| Phase | Old model (Node 26 and earlier) | New model (Node 27 onward) |
|---|---|---|
| Major releases per year | Two (April and October) | One (April) |
| Odd-numbered "Current only" releases | Yes, roughly 6 months of life | Retired entirely |
| Alpha phase | Not formalized | 6 months (October to March) |
| LTS promotion | Every other release, each October | Every release, each October |
| LTS support window | 30 months | 30 months (unchanged) |
The working group's own words make the practical impact clear for most developers: "If you already only upgrade to LTS versions, little changes beyond version numbering. LTS support windows remain similar, and now every release becomes LTS." That is the point most coverage of this change undersells: for the majority of production users, this is a renumbering exercise, not a new support promise.
The Real Fix Is Fewer Branches, Not a Better Label
Calling every release "LTS" is good PR, but it does not change how much work the release team actually does. The number of concurrently supported LTS lines is still governed by the same math: a 30-month support window and one promotion a year means roughly two to three LTS branches overlapping at any given time, the same as before. What disappears is the extra odd-numbered Current branch that existed every single year purely to give early adopters a preview, while still requiring the same security backporting discipline as every other branch. It is the same resource constraint behind open source's broader maintainer funding problem: volunteer time, not code quality, is usually the scarce resource.
That is the actual efficiency gain, and it is a modest one: removing a branch that almost nobody ran in production but that still consumed volunteer hours for roughly six months a year. If you have followed Node.js's comparisons with Deno and Bun, this is the kind of maintainer-capacity problem that newer, VC-funded runtimes do not yet have to solve, because they have not existed long enough to accumulate a decade of release lines.
Why Some Developers Pushed Back
The change did not land without friction. According to InfoQ's reporting on the public discussion in the nodejs/Release GitHub repository, Node.js contributor James Snell acknowledged that the old model "was based entirely on corporate adoption cycles that were relevant at that time" and needed revisiting. But other contributors raised a real cost: InfoQ reported that engineer Kevin Lentin warned the new annual cadence could create gaps of roughly two years between major versions for teams accustomed to upgrading more frequently, since skipping even one yearly release now means waiting twice as long to catch up.
That tension is the honest caveat most summaries of this change skip. The proposal, credited to Node.js Technical Steering Committee member Rafael Gonzaga per InfoQ's report, clearly solves a maintainer-capacity problem. It does not obviously solve, and may slightly worsen, the experience of teams who liked having a lower-stakes, six-month preview of the next major version before committing. Under the old system, a team willing to run Current in a non-critical environment got a new major release to experiment with every six months. Under the new system, that same team waits a full year between any new major release at all, Alpha included.
Who This Affects and Who Can Ignore It
This change matters most to platform and infrastructure teams who plan Node.js upgrade cycles on a fixed calendar, and to library maintainers who have to decide which major versions to keep testing against. It matters far less to the average application developer who already treats "upgrade to the current LTS" as a once-a-year or once-every-two-year chore.
- Act on this now if: you maintain a library or framework that tracks Node.js Current for early compatibility testing, since your testing calendar just moved from a six-month cadence to a twelve-month one.
- Act on this now if: your organization's upgrade policy explicitly references "even-numbered" or "LTS-only" Node.js versions by rule, since that rule no longer maps cleanly onto the version numbers after Node.js 27.
- Skip this for now if: you already only ever install whatever Node.js version is currently in LTS and ignore everything else. The working group says directly that little changes for you beyond the number you type.
- Skip this for now if: you are managing dependencies with a tool like those compared in our pnpm vs npm vs Yarn breakdown, since package manager choice is unaffected by this runtime-level scheduling change.
What to Watch Next
The next real test of this change arrives in April 2027, when Node.js 27.0.0 ships as the first major release under the new rules. If the project holds the line at one release a year and the community does not push for a mid-cycle "Current" escape valve, the change will have genuinely reduced maintainer load without costing most users anything. If pressure from fast-moving teams forces the project to reintroduce some form of interim release within the next two years, that will be the clearest sign the one-release cadence undersold how much demand there was for Node.js's old six-month preview window.
For now, the sensible move for most teams is to do nothing differently: keep tracking LTS, and note that your next decision point is Node.js 27's LTS promotion in October 2027, not anything happening this month. For library maintainers and platform teams who rely on early access to test compatibility, the move worth making is adjusting your internal testing calendar now, before the longer gap between major versions catches your roadmap by surprise.
Top comments (0)