Use lts version instead of version number.

[mkrawczuk]

The guide insists on using the LTS version of Node anyway. This change
will spare the documentation maintainers from bumping the version
manually each time a new LTS version is released. It also lets avoid
inaccuracies with version bumping. An example of such inaccuracy
occurred between commit de5f7ef, where the Node version was changed
from carbon to 8, and commit b0dd55c, where the version was
changed from 8 to 10 only in some places of localized guides.

[Trott]

@nodejs/docker

[nschonni]

I don't think it is usually a good idea to use an alias tag as it can also break as the LTS versions change. Not sure what the current recommendation is from the https://github.com/nodejs/package-maintenance repo since I think they were looking at some recommendations for test matrices

On the flip, this text does specifically talk about using LTS

[mkrawczuk]

Otherwise you are left with an untrue statement which indicates an older version of LTS. This is far more confusing and error-prone, as proven in my commit message. The lts tag should always indicate to the latest stable version, and I suppose it can be relied on. An experienced user will know exactly which Node.js version to use in the project in case of special needs. I also believe that the small example given in this guide should work with any stable version, unless major API changes occur inside Node.js .

[SimenB]

I brought this up here: #2293 (comment)

I don't have strong opinions one way or the other, although I'm partial to keeping this as-is and adding a checkbox to some release process saying "if this is first LTS release for this major, update nodejs.org". It happens once a year and not too onerous, is it? Of course, it wouldn't be me making that update, so I might be very wrong 🙂

[kaimallea]

The problem with static tags like lts and latest is that they represent a version number that is always changing, and at a certain point you don't know which version you're getting. This creates an unnecessary risk in a production environment. For example, if I pull the down the lts image on October 19, I will get Node 12. If my colleague pulls down the image on October 20, she will get Node 14. It's even worse in an environment where many teams are using CI with build agents that cache Docker images. If you're not using an explicit version number, there will be trouble.

With all of that said, you could make the argument that for the sake of a tutorial and its maintenance, it's okay to use lts. And I would agree. Except we all know people just copy & paste and

Maybe a good tradeoff is using lts in the guide to reduce maintenance, but include a comment or call out somewhere noticeable that in practice it's best to be explicit to prevent surprises.

[Trott]

Would it be possible to change it to lts but also include a comment that says to change it to a static number for production environments and that this is only appropriate for development or sample code or something like that? This way we don't have to add one more item to the release process (which already has an onerous number of tiny steps), we don't have the guide going out of date periodically, but we're also not recommending an anti-pattern.

[mkrawczuk]

I believe even the best tutorial will not prevent anyone from misusing software. And you cannot take responsibility for that.

I would go with adding a comment stating that in production environment the Node version should most likely be chosen explicitly - for example in cases of legacy projects that somebody decided to encapsulate in a dockerized environment.

[nschonni]

Closing as #2983 bumped it to 12