· via dev.to (home feed)
Node.js drops to one major release a year as maintainer workload forces schedule change
Node.js is ending its decade-old twice-yearly release cadence, retiring the short-lived odd-numbered lines and promoting every major version to LTS as the release team struggles to maintain up to five live branches.

One major release a year from October 2026
Node.js is ending the release cadence it has followed for roughly a decade. From October 2026 the project will ship one major version per year instead of two, and the odd-numbered "Current-only" releases — lines that lived for about six months and never reached long-term support — are being retired entirely. The change was announced by the Node.js Release Working Group, and a dev.to analysis argues the schedule shift is less about developer convenience than about the release team running out of capacity.
The transition is staggered. Node.js 26, the final release under the old rules, shipped on May 5, 2026 and enters LTS in October 2026; it stays in LTS until October 2027 and reaches end of life in April 2029. Node.js 27 is the first release built under the new model: a six-month Alpha phase from October 2026 to March 2027 for breaking changes and early testing, a 27.0.0 release in April 2027, a six-month Current period for stabilisation, then LTS from October 2027 until end of life in April 2030.
Every release becomes LTS, but the window stays the same
The detail that drew attention is that every major version will now be promoted to LTS. According to the working group, users who already upgrade only to LTS versions will see almost nothing change apart from the version number itself, because the 30-month support window is unchanged. One promotion per year against a 30-month window still leaves roughly two to three overlapping LTS branches alive at any moment, the same as before.
What actually disappears is the odd-numbered Current branch. The working group's usage data, cited in the dev.to piece, showed those releases saw minimal real-world adoption — most production teams skipped them and waited for the even-numbered LTS line. Even so, maintainers still had to backport security fixes into each odd branch for the six months it existed. Stacked on top of several live LTS lines, that left the team patching four or five active branches simultaneously, and the new schedule exists to shrink that count.
The working group also notes the old plan dated back to the 2015 io.js merger and was essentially a guess about enterprise needs made at the time.
Contributors flagged the cost for fast-moving teams
The change drew pushback in the public discussion on the nodejs/Release GitHub repository. According to InfoQ's reporting, contributor James Snell conceded the old model reflected corporate adoption cycles that were relevant ten years ago. Engineer Kevin Lentin warned that teams accustomed to frequent upgrades could face gaps of roughly two years between major versions, because skipping a single annual release now means waiting twice as long to catch up. InfoQ credits the proposal to Technical Steering Committee member Rafael Gonzaga.
The trade-off is tangible: under the old system, a team running Current in a non-critical environment got a new major version to experiment with every six months. Under the new system, that team waits a full year between major releases of any kind, Alpha included.
Why it matters
This is a symptom of open-source maintainer burnout rather than a product decision. Volunteer time, not code quality, is the scarce resource, and Node.js — unlike the VC-funded Deno and Bun runtimes — carries a decade of accumulated release lines. The dev.io analysis also points out the contrast with browsers: Chrome, Edge and Firefox have accelerated to two-week release cycles while Node.js slows its major-version cadence, because the two kinds of projects are solving different maintenance problems.
Concretely, platform and infrastructure teams that plan upgrades on a fixed calendar, and library maintainers who track Current for early compatibility testing, just moved from a six-month to a twelve-month cadence. Organisations whose upgrade policies reference "even-numbered" Node.js versions by rule will find that rule no longer maps cleanly to version numbers after Node 27. LTS-only application developers can largely ignore the change. The first real test of the new model arrives in April 2027, when 27.0.0 ships.
- #node-js
- #javascript
- #open-source
- #release-management
- #maintainers