tools: add 12.x to alternative docs versions

[richardlau]

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[nodejs-github-bot]

Lite-CI: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/3490

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/23065/

[mscdex]

Perhaps this kind of thing could be added to the list of tasks when cutting a new major version (if such a thing exists) to avoid missing this in the future?

[richardlau]

Perhaps this kind of thing could be added to the list of tasks when cutting a new major version (if such a thing exists) to avoid missing this in the future?

Should be added to #25497. I'll add a comment there. (edit: #25497 (comment).)

[BridgeAR]

I would actually like to automate this instead of making it part of our release process. We are definitely able to already detect the possible versions by parsing the changelog folder and their filenames. This won't provide us with any information about the current LTS status though. We could just expect every even release to be LTS for releases from v6 on or shall we only mark active LTS releases as such? In that case we could also parse https://github.com/nodejs/Release/blob/master/schedule.json (but relying on another repository does not seem ideal).

I might also have missed more ways to automate this but I really think we should minimize manual work as much as possible.

[richardlau]

I would actually like to automate this instead of making it part of our release process. We are definitely able to already detect the possible versions by parsing the changelog folder and their filenames. This won't provide us with any information about the current LTS status though. We could just expect every even release to be LTS for releases from v6 on or shall we only mark active LTS releases as such? In that case we could also parse https://github.com/nodejs/Release/blob/master/schedule.json (but relying on another repository does not seem ideal).

I might also have missed more ways to automate this but I really think we should minimize manual work as much as possible.

That's not a bad idea -- I can take a look at that.

[richardlau]

I would actually like to automate this instead of making it part of our release process. We are definitely able to already detect the possible versions by parsing the changelog folder and their filenames. This won't provide us with any information about the current LTS status though. We could just expect every even release to be LTS for releases from v6 on or shall we only mark active LTS releases as such? In that case we could also parse https://github.com/nodejs/Release/blob/master/schedule.json (but relying on another repository does not seem ideal).
I might also have missed more ways to automate this but I really think we should minimize manual work as much as possible.

That's not a bad idea -- I can take a look at that.

Let's close this one in favour of #27661.

[richardlau]

Reopening as a quick fix because #27661 in its current form won't work as expected outside of master.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/23067/

[ChALkeR]

As a side note: why is 6.x labelled as LTS and 4.x is not?
Both are EOL, so those should either both have the LTS label or not (or even have an EOL label).

Refs: #20904 nodejs/Release#440

[richardlau]

As a question: why is 6.x labelled as LTS and 4.x is not?
Both are EOL, so those should either both have the LTS label or not (or even have an EOL label).

Refs: #20904 nodejs/Release#440

@ChALkeR Good point. I've pushed another commit that marks 6.x as End-of-Life and removed the column for it from the changelog similarly to what we did for 4.x in #21612.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/23101/

[Trott]

Landed in 38e11cc...4a18b87