Node.js Is Moving to One Major Release a Year. What That Means for Your Upgrade Plan

Node.js is retiring its odd/even release model. Starting with Node.js 27, the project moves from two major releases a year to one, and drops the distinction that meant only half of them ever became Long-Term Support. If you plan infrastructure upgrades around Node’s release calendar, and most backend teams running Node in production do, this changes the shape of that calendar starting this October.

What’s actually changing

Under the model Node has used for years, a new major version shipped every six months, alternating odd and even numbers. Only even-numbered releases, 20, 22, 24, 26, were promoted to Long-Term Support after their initial Current phase. Odd releases existed mainly as an early testbed: real users could try them, but production adoption was consistently minimal, because most teams only ever deploy LTS versions.

The new model collapses that into a single yearly release:

Phase	Duration	What happens
Alpha	6 months (October-March)	Early testing, semver-major changes still allowed
Current	6 months (April-October)	Stabilization, the release most teams evaluate before committing
LTS	30 months	Long-term support, security fixes
Total support	36 months	From the start of Current to end of LTS

Node 26, shipped April 2026, is the last release under the old system. Node 27 starts its Alpha phase in October 2026, reaches Current in April 2027, and every release from here forward follows this same cycle. No more odd-numbered releases that most of the ecosystem never touches in production.

Why Node is making this change

The Node.js team gave three reasons, and they’re worth taking at face value rather than reading as spin:

Low real-world adoption of odd releases. If almost nobody deploys the odd-numbered line to production, maintaining it as a full parallel release track produces relatively little value for the actual burden of keeping it stable and current.

Maintainer sustainability. Node is maintained substantially by volunteers. Backporting fixes across two concurrent, actively-supported release lines is real ongoing work. Reducing to one release stream per cycle cuts that overhead without meaningfully reducing what users get, since the version most people run was always the even-numbered LTS line anyway.

Predictability for planning. A fixed April/October cadence, one release a year, every release eventually reaching LTS, is simpler to plan against than remembering which numbers matter and which are a testing detour.

What this means for your upgrade plan

If your team already follows the sane default, LTS-only in production, this changes less than the headline suggests. You were never deploying odd releases anyway. What changes is more subtle:

There’s no more “skip this one” release. Previously, an odd-numbered release you saw mentioned in changelogs or GitHub issues was, by design, not the one you’d deploy. Now every release is a real candidate. If you’ve built a habit of ignoring every other Node.js announcement, that habit no longer maps to a real distinction, pay attention to all of them.

Early feature testing moves to the yearly Current phase. If your team liked testing bleeding-edge Node features against an odd release before committing your codebase to a real upgrade, that testing window is now the same Current phase everyone else is watching, not a separate low-stakes branch. Budget testing time accordingly, that six-month Current window is now the only place to catch a breaking change before it ships as LTS.

Your LTS transition timing gets a fixed, predictable calendar. October alpha, April current, then 30 months of LTS from there. If you manage infrastructure for multiple projects on different Node versions, you can now plan a yearly upgrade cadence with dates you actually know a year in advance, instead of tracking two parallel timelines.

Practical next step

If you’re currently running Node 24 (LTS through April 2028) or Node 26 (Current, on track for LTS), you don’t need to do anything urgently. The change affects the release you’ll eventually plan for after 26, not the one you’re on today. What’s worth doing now is updating whatever internal runbook or dependency-upgrade calendar your team keeps to reflect the new April/October cadence, so the Node 27 alpha in October doesn’t catch anyone off guard as a surprise release cycle change rather than the expected next step. It’s the same discipline worth applying to the indexes on your database tables: a scheduled, deliberate review beats reacting after something quietly gets slow.

We’ve helped a number of clients build dependency and runtime upgrade schedules that survive contact with a real production system rather than living only in a wiki page nobody revisits. A predictable release calendar like this one is exactly the kind of external change that upgrade planning should absorb quietly, not one that shows up as an emergency six months from now.