SSerguey Asael Shinder
Java coding notes: the JVM, and writing software that lasts

Serguey Asael Shinder: An LTS label is a promise about the future, not a change in the code

· by Serguey Asael Shinder / Serguey Shinder

Node.js 26.13.0 came out this week, and its release notes are almost empty on purpose. The 26.x line moves into long-term support under the codename "Lithium", with updates through the end of April 2029. Apart from metadata such as process.release, which now reports the line as LTS, the release contains no changes from 26.12.1. (https://github.com/nodejs/node/releases/tag/v26.13.0)

I like that release because it makes something visible that usually hides inside a version number. The code you run on Tuesday is byte-for-byte what you ran on Monday. What changed is a commitment: someone has promised to keep backporting security fixes and critical bug fixes to this line for two and a half years.

Serguey Asael Shinder: An LTS label is a promise about the future, not a change in the code
An LTS label is a promise about the future, not a change in the code — Serguey Asael Shinder

That commitment is the property production depends on, and it is easy to confuse with stability of the code. A "stable" release is one that does not break today. A supported release is one that will still be fixed when something is found next year. Teams often choose the first and assume the second. Then a vulnerability lands in a line that left support six months earlier, and the patch exists only in a version two majors ahead, with a migration nobody planned.

Java has trained me to read versions this way. JDK 21 and JDK 25 are not better than the feature releases between them in any technical sense at the moment of release; they are the ones vendors have agreed to keep patching for years. When I pick a runtime for a service I expect to keep, the first question is not "what does this version add" but "until when will anyone fix it, and what is my plan for the day after".

The practical habit is cheap. Put the end-of-support date of every runtime you deploy next to the service in whatever inventory you keep, and treat the date as a deadline with an owner. The same release notes carry a second reminder worth reading: anyone moving from Node 24 or 22 should know that the Linux binaries have linked against libatomic since Node 25. A support window protects you from future bugs; it does not protect you from the upgrade you postponed.