Coordinating a couple words of clarification around the meaning of LTS
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
https://github.com/nodejs/nodejs.org/pull/7962#pullrequestreview-2998862184
and two small improvements suggested on the website
https://github.com/nodejs/nodejs.org/issues/7965 https://github.com/nodejs/nodejs.org/issues/7966
also worth mentioning that https://github.com/nodejs/Release?tab=readme-ov-file#release-schedule omits the word ACTIVE all together.
cc @nodejs/releasers @nodejs/release
I think normalizing to "Active LTS" and "Maintenance LTS" everywhere makes sense.
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.
TL;DR I agree we should normalise terminology within the project, but we should not be exposing that terminology on the website.
right - this effort pre-dated https://github.com/openjs-foundation/summit/issues/469 - which might change it all anyway