Node 24.x not yet marked as LTS ("Krypton") in index.json (website lists v24.10.0 as Latest LTS)

[MinaFayez9]

Version

Not applicable – issue concerns Node.js distribution metadata, not runtime behavior.

Platform

All platforms (observed on Windows, but affects all because index.json is global).

Subsystem

Release / Distribution metadata

What steps will reproduce the bug?

1. Visit https://nodejs.org/dist/index.json
2. Search for any entries for version v24.x.x
   → all of them have "lts": false.
3. Visit https://nodejs.org – it lists v24.10.0 as “Latest LTS”.
4. Tools that rely on index.json (Volta, nvm, fnm, etc.) still treat Node 22 ("Jod") as the current LTS.

How often does it reproduce? Is there a required condition?

Always, until the index.json is updated to include "lts": "Krypton" for Node 24 entries.

What is the expected behavior? Why is that the expected behavior?

When Node 24 is promoted to LTS (codename "Krypton"), each v24.x entry in index.json
should have an "lts" field set to "Krypton" rather than false.

Tools and automation use this field to determine the latest LTS line,
so keeping it accurate ensures consistency between nodejs.org and the dist metadata.

What do you see instead?

All v24.x entries in index.json currently show "lts": false,
while the homepage lists v24.10.0 as “Latest LTS”.
The most recent version marked as LTS in index.json is still 22.21.0 ("Jod").

Additional information

Date checked: 2025-10-28

Example entry from https://nodejs.org/dist/index.json:
{
"version": "v24.10.0",
"date": "2025-10-14",
"lts": false
}

Expected:
{
"version": "v24.10.0",
"date": "2025-10-14",
"lts": "Krypton"
}

This discrepancy causes tools such as Volta, nvm, and fnm — which rely on index.json
to determine the current LTS — to continue installing Node 22 instead of 24.

This seems like a metadata lag during the LTS promotion.
Just filing it here in case the release metadata hasn’t yet been updated.

Thanks for maintaining Node.js and for your work on the release process 🙏

[targos]

This is a bug with the website. The first v24 LTS will be v24.11.0 (to be released today)

[aduh95]

Duplicate of #7153?

[MikeMcC399]

@aduh95

Thanks for alerting me to this issue! I deleted my comment in nodejs/node#60414 to avoid any confusion (it was already set to off-topic).

[bmuenzenmeyer]

As of right now, the website is extremely data-driven, and we have found a number of places where missing data (ie: missing release overlaps, postponed or faulty releases, etc.) cause outages, only for it to correct once backing data is available.

Examples: #8217 and #8248

We should look for ways to hot-wire the behavior, such as a site.json override that allows us to force through LTS, Latest values.

Anything we do would impose it's own temporal constraints...to add and then remove as releases become available.

[targos]

I've said this several times but it seems my comment is always ignored: the source of truth is https://nodejs.org/download/release/index.json. You can stay data-driven if you use that.

[bmuenzenmeyer]

fair - for what it's worth, we use https://github.com/cutenode/nodevu/tree/main/core - i dont recall the origin of that decision. I am we can get to the bottom of it

[aduh95]

In particular, curl https://nodejs.org/download/release/index.json | jq first always returns the latest Current, and curl https://nodejs.org/download/release/index.json | jq 'map(select(.lts)) | first' always returns the latest LTS.

[bmuenzenmeyer]

It's one of those unfortunate types of issues that is wrong for a very short amount of time, but when naturally lots of eyeballs are drawn to the site.

I started looking into this. There are some reasons to use the nodevu logic. I think one solve would be to cross-reference it with the index.json to never OVERPROMISE release information that should be present based on a simple date comparison

[MattIPv4]

What do we actually need nodevu's additional support data for? I am very much in favor of just relying on our our dist file with the LTS flag it has?