Add shortcut for Oldest Maintained LTS

[sffc]

I am a library author. I want to make sure my library works in older Node.js versions. I figure that a good distance to go back in time is to the oldest maintained LTS version of Node.js.

For example, right now the oldest maintained version of Node.js is version 6. It would help if nvm had a notation like lts/maintenance to automatically select that version of Node.js.

This would be helpful for use in .travis.yml files.

[ljharb]

My personal recommendation is to support far older than that, and not constrain yourself to the platform’s EOL point, since many users still rely on older engines.

That said, this is a reasonable feature request.

[ghost]

I think that's a good idea. Implementing it could be fun.

For example, right now the oldest maintained version of Node.js is version 6. It would help if nvm had a notation like lts/maintenance to automatically select that version of Node.js.

Multiple LTS versions are being maintained at the same time if I'm not mistaken--v6, v8, and v10? So maybe something like nvm install lts-6 would be nice to have, along with a list command: nvm list lts, which would output all the lts version names that you could install.

As for older versions, that would be a completely different feature.

[ljharb]

@Bthompson90 the LTS version isn't "6", it's "boron" - there's no guarantee that boron will always be v6. Separately, after any nvm ls-remote command, nvm alias will always be up to date with all of the available LTS versions. I suppose I could add nvm alias --lts and it would only list the LTS versions.

This issue is solely about installing the oldest version.

[ghost]

@ljharb thanks for the clarification. I see that there's Boron, Carbon, and Dubnium, and that not all versions of v6 or v8 or v10 or covered under LTS. You stated that there's no guarantee Boron will not always be v6 so I guess the chosen LTS versions aren't static, which doesn't make complete sense to me.

[ljharb]

That's how LTS tends to work (and how node has chosen to implement it) - it's not coupled to version numbers.

[sffc]

To be clear, the behavior I had envisioned is: lts/maintenance maps to lts/X where X is the oldest LTS stream still within its maintenance window. For example, according to the release schedule:

• Until April 2019, lts/maintenance maps to lts/boron
• From April 2019 through December 2019, lts/maintenance maps to lts/carbon
• From December 2019 through April 2021, lts/maintenance maps to lts/dubnium

Within each window, I expect the latest version of the chosen stream. So, for example, today, if I were to request lts/maintenance, I expect to get version v6.16.0, the same as if I request lts/boron.

[ljharb]

That’s exactly my assumption; thanks for writing it out so clearly.

[ghost]

I should've done my homework on Node's LTS implementation; apologies there. Thank you for being patient with me.

I agree that it'd be a nice feature to have.

[saschanaz]

My personal recommendation is to support far older than that

How about something like lts/*-1, lts/*-2 for older LTSs?

[ljharb]

@saschanaz That seems arbitrary; I suggest supporting down to node 0.6 if possible.

[saschanaz]

supporting down to node 0.6

That would be great, but I doubt maintainers would be happy with that... Supporting last few LTS versions has been good enough for us in ReSpec/webidl2.js.

[ljharb]

With 4626d1a, I've added the feature where you in addition to lts/* for "latest LTS", you can now use lts/-1, lts/-2, etc to get the "nth-ago LTS line's latest".

This way, you can decide you're supporting "the current LTS line, plus the last two" and your CI matrix etc can just float along with those releases.

With that, I'm going to close this, because having to do date math on the support date, and with the current date, is not, I think, worth the complexity :-) (see also #2170)

[piranna]

having to do date math on the support date, and with the current date, is not, I think, worth the complexity :-)

In fact, that's what this feature should do... :-(