Docker-node: Add tag LTS suffix

[webysther]

Is possible add this tag, sample:

6.11.3-lts, 6.11-lts, 6-lts, boron-lts
8.5.0-lts, 8.5-lts, 8-lts, lts (when 8 comes LTS)

More info: https://github.com/nodejs/LTS

[Starefossen]

I am neutral to having an LTS suffix, but there is definitively an overhead of adding it as we will have to support the existing tag naming convention as well.

I am definitively opposed to having an lts tag since there is nothing "long term" nor "stable" about it since it will move to the next lts release as soon as the next one is out – essentially breaking lots of stuff.

[webysther]

"...essentially breaking lots of stuff" for using :latest or :alpine too.

Overhead to created automated tag or for build? To me, layers keep cached and tags works like alias like with any other tag.

[chorrell]

RE: boron-lts I thought "boron" and other named releases implied LTS?

[webysther]

@chorrell Without boron-lts or argon-lts how i switch between LTS? We have argon and boron.

[Starefossen]

This is similar to how Ubuntu and Debian images are tagged. I have seen no other official images that has explicitly named any of their tags LTS.

[webysther]

@Starefossen In no official repository is the LTS tag used, for me it is important to use only LTS (despite all the discussion about the term itself) by guaranteeing a longer support and other stuff. Is there something I am not realizing to use LTS more automatically?

[tianon]

In "mediawiki", "sonarqube", and "xwiki" the maintainers have opted for an
"lts" tag (and "latest" then points to the most recent release). However,
in "ubuntu", the "latest" tag simply points to the most recent LTS instead
(since that's what users who don't know what they need ought to be using).

[Starefossen]

@Webysther the problem with an LTS tag for a programming language like Node.js is that this tag will b be moved to the next LTS version as soon as the next one is out, and since there are one major release in-between LTS versions there will be seriously (and sudden) breakage for all project relying on the lts tag – this is similar to what happens with the latest tag which is highly discouraged to use.

@tianon thanks for you input, I guess an lts tag makes sense for some software applications, and I am much more inclined to move the latest tag to the latest LTS version; I guess it is not an option to remove the lateset tag altogether.

[SimenB]

I like having latest point to the latest LTS. Can we do that from when 8 is LTS and onwards (so as to not break current latest usage)?

[pesho]

I like having latest point to the latest LTS. Can we do that from when 8 is LTS and onwards (so as to not break current latest usage)?

:+1: I like that as well.

[LaurentGoderre]

What would be the tag for the version past LTS if not latest? I think latest should be to the latest available version and lts should be on the latest LTS version. If that doesn't meet someone's need, they should use version numbers.

[pesho]

@LaurentGoderre the version past LTS can be specified using version numbers/names.

I'm against an lts tag because using it would be a bad practice, and we shouldn't encourage it. People who target LTS do it because they value stability. However, a tag which can jump between LTS versions (e.g. 6.x to 8.x) is anything but "stable".

[chorrell]

I agree. I've been discouraging the use of latest for as long as I've been working on this. Creating another similar tag is going to lead to all kinds of issues.

The original request of the OP was to add an LTS suffix. It seems redundant given that we already tag LTS releases with their names (boron etc). Then again 6.11.3-lts, 6.11-lts or 6-lts is at least more meaningful to most people than boron

[marandalucas]

examples:
node:8.9.4-alpine-lts
node:8.9.4-slim-lts

thanks for the good work

[jhclouse]

I understand the concern about breaking code because the major version jumps suddenly. But there are valid use cases for this.

In my case, I want to have my build server build the develop branch with whatever the latest LTS is. If there are problems, automated tests will catch them. The release branch will still be locked down to a specific major version until changed manually.

The option should be there for those who want to use it. And if somebody screws up it's on them.

[fkorotkov]

Agreed with @jhclouse. Also it will be great to not only have lts tag but a tag for the latest maintainable lts as well. For example, call this tag maintenance-lts. This way it will be easier to configure CI to run some compatibility tests on these tags.

[davidkassa]

What I'm personally looking for is a latest-lts tag. I want the latest, but on the lts branch.

[CraigGardener]

Running tests using CI would definitely be easier with additional tags for LTS and perhaps current.

I do not wish to update CI configuration for all my projects when a new version is released, however I always want to test against LTS and current versions.

I would like to be able to use current tags such as:

• current-alpine - currently 10.5.0-alpine, 10.5-alpine, 10-alpine, alpine
• current-slim - currently 10.5.0-slim, 10.5-slim, 10-slim, slim
• current-stretch - currently 10.5.0-stretch, 10.5-stretch, 10-stretch, stretch
• current-jessie - currently 10.5.0-jessie, 10.5-jessie, 10-jessie, jessie, 10.5.0, 10.5, 10, latest

And lts tags such as:

• lts-jessie - currently 8.11.3-jessie, 8.11-jessie, 8-jessie, carbon-jessie, 8.11.3, 8.11, 8, carbon
• lts-alpine - currently 8.11.3-alpine, 8.11-alpine, 8-alpine, carbon-alpine
• lts-onbuild - currently 8.11.3-onbuild, 8.11-onbuild, 8-onbuild, carbon-onbuild
• lts-slim - currently 8.11.3-slim, 8.11-slim, 8-slim, carbon-slim
• lts-stretch - currently 8.11.3-stretch, 8.11-stretch, 8-stretch, carbon-stretch

Having looked at what I've posted above, it occurs to me that the current tags are not required as jessie, alpine etc. refer to the current version.
The concerns regarding breaking code when there are major version changes to the lts tag are no more valid than any concerns related to the jessie, alpine etc tags.

Given that we offer users the option to automate testing (or screw things up) by using the jessie, alpine tags, why don't we also provide a similar option for lts versions?

I agree with @jhclouse that "if somebody screws up it's on them".

[webysther]

After a while, the ubuntu and debian change their mind about lts and change to something like that (https://hub.docker.com/_/ubuntu/):

The ubuntu:latest tag points to the "latest LTS", since that's the version recommended for general use.
The ubuntu:rolling tag points to the latest release (regardless of LTS status).

[chorrell]

I prefer that approach.

[CraigGardener]

Whichever approach is decided on, it appears there's a fair bit of interest in adding tags for the "LTS" and "Current" releases.
It doesn't bother me whether latest = lts or latest = current as long as I have 2 consistent tags to use that will always refer to the 2 versions on the NodeJS homepage!

Does it make sense to tag the two versions lts and current (as per the nodejs homepage) and save the "what should latest mean" discussion for later?

[lifeiscontent]

any updates on this?