Coordinating a couple words of clarification around the meaning of LTS

[bmuenzenmeyer]

https://github.com/nodejs/Release defined the three phases of a Node.js release

• Current
• Active LTS
• Maintenance

And yet the SVG does not use the word LTS anywhere within it. Further, the SVG should match the language we have within https://nodejs.org/en/about/previous-releases

Production applications should only use Active LTS or Maintenance LTS releases.

See the PR where this was brought up

nodejs/nodejs.org#7962 (review)

and two small improvements suggested on the website

nodejs/nodejs.org#7965
nodejs/nodejs.org#7966

[bmuenzenmeyer]

also worth mentioning that https://github.com/nodejs/Release?tab=readme-ov-file#release-schedule omits the word ACTIVE all together.

[ovflowd]

cc @nodejs/releasers @nodejs/release

[targos]

I think normalizing to "Active LTS" and "Maintenance LTS" everywhere makes sense.

[richardlau]

There was a brief discussion at the recent collab summit around terminology.

We should not confuse users of Node.js with active/maintenance labels on LTS. As far as users are concerned a Node.js release line should be in one of these states:

• Current
• Long Term Support
• End-of-Life

It is important to note that at any time there may be one or more release lines in any of those states (e.g. there may be two release lines in Current state, or two (or more) releases in LTS).

We need to distinguish the terminology we use externally (i.e. on the website) and internally (i.e. in the Release WG and with collaborators) to communicate the policy in terms of when it can be expected that features are considered to land on LTS lines (for us this is Active LTS), or when the default position is "at the discretion of the Release WG" (i.e. Maintenance). This may mean we need two versions of the SVG -- one for use within the project and a different one for the website.

[richardlau]

TL;DR I agree we should normalise terminology within the project, but we should not be exposing that terminology on the website.

[bmuenzenmeyer]

right - this effort pre-dated openjs-foundation/summit#469 - which might change it all anyway