Do we really need codenames for LTS releases?

[jasnell]

This issue is intentionally left open for the discussion of the pros/cons of having LTS codenames. The thread is intentionally locked for non-Collaborators. Once the v6 rolls over into LTS and we give it a few months, the LTS WG plans to revisit whether or not LTS releases should have code names at all. We plan to wait until there's sufficient time to determine the utility of having the codenames with two parallel LTS streams.

[bnoordhuis]

Speaking for myself, I don't really see value in code names. I don't think I've ever called v4 "argon", I call it "v4." :-)

I never hear other people call it "argon" either, come to think of it.

[jasnell]

doh! accidentally had this thread locked!! my apologies all.

[jsumners]

The even and odd numbering, along with listing the LTS status for good measure, is sufficient. As @bnoordhuis said, I have never referenced releases by codename (I'd have to look them up) and have never heard anyone else do so either.

[gibfahn]

I seem to recall someone saying the codename was useful for docker images ( I think so you can pull boron:latest instead of 4:latest), but I don't recall the details (maybe it was @chorrell?)

EDIT: I guess I was wrong, +1 to dropping them.

[chorrell]

Not really. It's more intuitive for most people to just do:

docker pull node:4
docker pull node:6

The codenames are just another tag for the same image (node:boron is the same as node:6 for example).

In terms of the docker image, the codenames aren't that important imo.

[jasnell]

When codenames were introduced, the idea was to give it a try for a couple of LTS cycles then re-evaluate to see if they truly are useful. There has definitely been a mix of opinions but given that the question keeps coming up and we do not seem to have anyone jumping up and down proclaiming the glorious benefits of codenames, I'm inclined to agree to dropping them going forward -- especially given that tooling like docker and version managers really do not have a strong use case for using them.

tl;dr ... +1 to dropping them.

[mhdawson]

I'm neutral. I'm fine having them but would not argue for them if the consensus is that they don't add value.

[xzyfer]

As a consumer I appreciate LTS codenames. They're valuable for adding context to non-node centric developers. A good example where we have found them useful is in Travis CI scripts.

node:
- lts/boron
- lts/argon
- current

Conveys intent better than

node:
- 4
- 6
- 7

[nschonni]

What would happen to the index.tab/json if the names went away? https://nodejs.org/dist/index.json
Would the lts property become a floating true/false per LTS applicable Node version?

[Trott]

@jasnell Should this remain open?

[jasnell]

Have we actually reached a decision on this?

[Trott]

Have we actually reached a decision on this?

Simple question with many layers!

TL;DR: No explicit decision has been made but it also likely won't be made in this issue, so let's close.

First: It depends on what you mean by your question.

If you're talking about the community at large, there's no way there will be consensus on this. Lots of people will think codenames are useless. Lots will think they're essential. And most people will fall somewhere in the middle.

If you're talking about the project members, same story there.

If you're talking about the Release WG, then I don't know. You tell me! But I suspect the story there will be similar.

If you're talking about letting process run its course, then unless Release WG intends to step in to make the call, we're stuck with status quo. So releases will have names.

Second, and more important: There seems to be an implication in the question that if a decision hasn't been reached, then we should leave this issue open and have more conversation until we arrive at a decision. The problem is that we will never arrive at a decision that way. By and large, this conversation has already happened in #291 (and probably elsewhere). There was no resolution in that issue. I don't think more conversation is going to change that.

So, there are really two options:

• Release WG steps in and says "Nope, we don't need codenames anymore." That seems possible but unlikely to me. (You likely have a better sense than me, though.)

• More likely scenario: Status quo wins out. We keep codenames. (Same result if Release WG steps in and says we need codenames.)

Even though I don't think the codenames are very useful for the most part, I'm for status quo on this because I don't think it's worth the effort to overcome the inertia here and get rid of them, and they aren't that problematic except for the unnecessary conversations they generate that run the risk of drowning out more substantial conversations. To that end, if Release WG would simply choose and publish the names ahead of time, that would solve the problem, probably. See #317.

[ljharb]

nvm requires codenames to function properly around LTS targeting; it will be a very painful change to try to get nvm to work without them and also get it deployed widely enough prior to codenames going away.

[Trott]

I think the fact that nvm requires codenames along with the relative lack of consensus formed during conversations about this in other issues points squarely at: "We're going to have codenames for a long time." I think this issue should be closed.

[noogen]

With the upcoming v10 and the popularity of the initial/old nodejs 0.10, I think codename would be helpful with searches? I just happen to try to search for news of v10 on google and get a lot of old nodejs 0.10 stuff.

Alternatively, bump the version up to 13 (to skip 0.12 popularity) or start using year like v18 and so on. Ubuntu and Docker uses this pattern. Might be a dumb idea, I know, just throwing it out there.

[Trott]

Can someone close this issue? We're definitely keeping codenames around. nvm needs them. And there's not consensus on removing them, which means status quo.

I have sufficient privileges to close this issue, but I'm not on the Release team, so I'd prefer someone in @nodejs/Release / @nodejs/LTS do it...