Node.js Makes Every Release LTS From Version 27. The Odd-Version Skip Becomes an Alpha Test.

The Node.js project has published a new release schedule that starts with version 27. The change is easy to summarise and easy to misread: the official announcement says there will be one major release a year, released in April, and that every release will become LTS. The odd and even split that every Node team learned is gone. So is the advice that comes with it.

If your upgrade policy is "only run even-numbered versions once they hit LTS", it still works for Node 26, which is the last release under the old model. After that the policy needs a rewrite, and the interesting part is not the release count. It is the new six-month alpha phase that sits in front of every release.

What the new Node.js LTS release schedule says

Each release line now passes through four phases. Alpha runs for six months from October to March, and semver-major changes are allowed during it. Current runs from April to October as the stabilisation window. LTS then lasts 30 months, followed by end of life. Add it up and a release gets 36 months of support from its first Current build.

Version numbers will match the calendar year of the first Current release, so 27.0.0 arrives in 2027 and 28.0.0 in 2028. The project also says the schedule is not final and may be amended, and it names the schedule.json file in the nodejs/Release repository as the authoritative record of support claims.

Why "skip the odd versions" stops working

The old rule existed because odd-numbered releases never became LTS. Teams used the label as a free filter: if it is odd, ignore it. That filter let most of the ecosystem avoid testing against a new major until it was already stable.

Under the new model there is nothing to filter. Every April release is a future LTS, so the question "will we ever run this one?" always has the answer yes. What replaces the filter is time. Your team gets the alpha window from October to March, the Current window from April to October, and then a version that sits on the LTS line for two and a half years.

For application teams the practical effect is small. You still upgrade roughly once a year, and you can still wait for LTS in October. The difference is that your dependencies will have had a full year to react, which is the point of the alpha channel.

The alpha channel is a CI target, not a download

Alpha builds are signed and tagged, unlike nightly builds, and the project tests them with CITGM, which runs the test suites of major open-source packages against the upcoming version. They use semver prerelease numbering, for example 27.0.0-alpha.1. The project is explicit that they are not for production, and that some commits may be left out of an alpha.

The audience it names is library authors. If you maintain a package, add an alpha job to your CI matrix as soon as the first build appears this October. Allow that job to fail without blocking merges, and read the failures weekly. A breaking change that surfaces in alpha can still be argued about upstream. One that surfaces in April cannot.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        node: ['22', '24', '26']
        include:
          - node: '27.0.0-alpha.1'
            experimental: true
    continue-on-error: ${{ matrix.experimental == true }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci && npm test

Node 26 is the last of its kind, and it removes things

Node.js 26 was released in May 2026 and is due to enter LTS in October. The release notes list the Temporal API as enabled by default, which is the headline feature. The less visible part is the list of removals, and these are the ones that break builds.

• http.Server.prototype.writeHeader() is removed. Use writeHead() instead.
• The legacy stream modules _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform and _stream_passthrough are removed.
• The --experimental-transform-types flag is removed.

None of these is likely to appear in your own code. They do appear in old transitive dependencies, and a deep import of a _stream_ module is exactly what a 2016 package would do. A quick search of node_modules finds them before a container build does.

# direct usage in your source
grep -rnE "writeHeader\(|_stream_(wrap|readable|writable|duplex|transform|passthrough)|experimental-transform-types" src/ package.json

# transitive usage in installed dependencies
grep -rlE "require\(['\"]_stream_|\.writeHeader\(" node_modules --include=*.js | head -50

A revised upgrade policy for a small team

A short policy covers the new model. It assumes a team that runs a few services and does not want upgrades to become a project.

• Production runs the newest LTS. From October 2026 that is Node 26.
• CI runs the previous LTS, the current LTS and, from October, the alpha as an allowed-to-fail job.
• Upgrade production within three months of a version entering LTS, which leaves most of its 30 LTS months unused as buffer.
• Record the end-of-life date in the repository next to the engines field, and review it every April.

The tradeoff is real. A yearly cadence is less frequent than the old twice-a-year majors, so each jump carries more removals at once. Teams that skipped odd versions were already making one jump a year, which means the cost for them is roughly unchanged. Teams that tracked every Current release will see fewer, larger steps.

What to watch before April 2027

Two things decide whether the new schedule is boring or painful. The first is how often the project merges semver-major changes into alpha builds, because that sets how noisy your CI job will be. The second is how many popular packages ship fixes before 27.0.0 arrives. The October to March window is the first real test of whether the ecosystem uses it.