add support info to index.tab

[ljharb]

The index.tab file includes a column for LTS and one for security, but does not include an indication of support status. Could we include that info? i'm thinking support which is either eol, maintenance, lts, active, or current?

[richardlau]

The tool that generates index.tab/index.json is https://github.com/nodejs/nodejs-dist-indexer. I don't believe what is being asked for would require any process change for the releasers and could be done by having the tool read the information from schedule.json from the Release repository.

One consideration is that the current information in the file for a release is static (i.e. a value in any of the columns doesn't change for a release once in the file). The file is only updated AFAIK when a new release goes out, so any transient data (like being proposed) would possibly be out of date (for example a release going End-of-Life does not require a new release at the point that it does so).

[richardlau]

(btw lts is already a column in the index (set to the codename for LTS releases) and maintenance/active would only apply to LTS releases.)

[richardlau]

ping @nodejs/build as https://github.com/nodejs/nodejs-dist-indexer is "Managed under the governance of the Node.js Build Working Group".

[ljharb]

true, but that would mean that whenever the next release came out, the statuses would be updated.

[rvagg]

There are already a few tools out there that combine schedule.json with index.json to determine this, it's not difficult to do. Since index.json and index.tab updates are pinned to release timing, it's going to be regularly out of sync, but at least a week or two, whenever statuses change, then we'll get a flurry of issues of people telling us that it's out of sync.
I'm -1 for confusing the two sources, but would be happy for someone to document more clearly how you could combine them for interesting info. Or maybe just linking to those utilities that already exist. https://github.com/nw/node-release-lines is one, I believe @bnb may have forked or rewritten that to something new too?

[ljharb]

That makes sense, and i can do that, but it’d be nice if nvm didn’t have to make an additional network request and add another mirror compatibility point :-/

[BridgeAR]

@ljharb I guess at least for now there's nothing that we would want to change on our side. I understand that it's not ideal to add more network requests but that should not be too bad either, is it?
I am going to close this issue for now as I do not see any action items on our side left. Please leave a comment if you think this should be reopened.

[ljharb]

It’s pretty bad, enough that I’ll never do it.

You can leave this closed if you prefer, but my hope is that you’ll change your mind and provide a combined file :-)