Discuss possible clarifications to the LTS messaging / labeling

[jasnell]

Some of the community feedback about the LTS plan received at the Node.js Interactive conference was that the messaging around LTS is still too complicated. The labels, "LTS", "Stable" and "master" are a bit confusing. @mikeal, @ashleygwilliams and I had a brief conversation with a couple of folks from the Linux Foundation marketing team to discuss how the messaging can be improved and one of the ideas that came up was relabeling our release branches (e.g. "LTS" would become "Stable", "Stable" would become "Current" and "master" would become "Canary"). Obviously changing the labelling this soon after adopting the current labeling could end up causing even more confusion so we need to be strategic about any changes we decided to do.

Another of the ideas that came up was the notion of creating a formalized, community supported migration guide that would be proactively updated for each major release. The guide would exist as a microsite under the nodejs.org domain (e.g. migrate.nodejs.org) and would offer detailed assistance on how to move from one major node.js release to another, documenting the major changes, offering tips and being prescriptive with a clear migration path. This could be driven either through the @nodejs/documentation working group or through a new working group specifically chartered for stewarding the migration microsite.

[mikeal]

In terms of the naming and branding of the channels this is something we can also ask the foundation's marketing committee for feedback on. They've been dealing with trying to message this already within their organizations.

[rvagg]

I've had a lot of trouble with the "Stable" confusion when trying to communicate this too.

However, I'm not in favour of dropping "LTS" cause we've put so much effort into that and it already resonates with a large section of our user base, particularly at the operations end. It's also being increasingly used for software projects so is becoming more familiar to more users. There's no reason we can't refer to our LTS branch as being stable if we rename what we currently call "Stable", we're restricted in doing this at the moment so we have to find awkward language to describe it.

I'd also rather us not use "Canary" for our master branch because it's not a canary build in the same way the Chromium uses the term. It's more like "Next", but even that may be misleading because it's not strictly true.

Re

community supported migration guide

Great idea, but docs have been hard to get solid attention on. Everyone loves having good docs but not many people like writing them. As I've suggested here, I don't think the docs WG has been able to form much of an effort around our existing documentation. Perhaps this work is best started as an entry in the nodejs/node wiki as an extension to the docs on API differences between major versions—which themselves are always a major effort to put together because few people are inclined to put in that work (for instance, do you see any docs for v5? https://github.com/nodejs/node/wiki, and the 0.10 to v4 docs are almost entirely the work of @Fishrock123 alone, who NodeSource supported to do this work).

Perhaps the question here is how we can best set up a bootstrap or framework that others can contribute to without locking ourselves into supporting something that may not end up getting new contributors (as opposed to any of the existing stretched contributors).

[mikeal]

I don't think this is a binary decision, it's not about dropping LTS entirely, but instead making moving the label to "Stable."

LTS should still be a part of the messaging, it's what we're committing to that makes it stable.

I'd also rather us not use "Canary" for our master branch because it's not a canary build in the same way the Chromium uses the term. It's more like "Next", but even that may be misleading because it's not strictly true.

Another alternative is "Unstable." That would also re-enforce that "Current" is stable enough to use even if the main label isn't "Stable."

[mikeal]

Great idea, but docs have been hard to get solid attention on. Everyone loves having good docs but not many people like writing them.

Agreed that this is a challenge but if we decide it's important we can get more resources on it. Also, we have also talked briefly about a micro-site, something beyond just docs, that is focused solely on migrating to new versions.

[ashleygwilliams]

hi! i was part of the discussion at Node Interactive with @jasnell and @mikeal. most of my opinions have been communicated, but not my commitment to producing/maintaining these documents, particularly the microsite.

would like to hop on a call to talk about this further and get the effort going.

[gtewallace]

hi all - I too was in that meeting at Node Interactive with @jasnell and @mikeal , tho majorly drinking from fire house (week 1 on the job), so maybe present more in body than mind ;)

my $.02 after reading this thread and the LTS Meeting - #64 :

1. keep LTS - seems like there's some momentum and certainly infrastructure built up around LTS, such that any change could add to, not diminish, the communication work. Also, it is actually pretty descriptive, IMO
2. change Stable - For me, this is the confusing one. I actually like @rvagg 's (sort of) suggestion of Next. I get that it's not strictly true, but to me it is descriptive of why someone would use it - to have access to the latest tech and to preview the direction for the upcoming LTS. Unstable probably is even more descriptive, but I wonder if that would actively discourage its use more than we'd like...
3. what to do with Master - I don't have any thoughts here really (PUNT).

More generally, when considering whether to change a label, perhaps the test should be "are there other labels that are undoubtedly more clear?" For me, with LTS I'd say No. For Stable I'd say Yes, and for Master I'd say I don't know.

@ashleygwilliams for the migration micro site and docs, let's def get on a call. you available next week? I am finishing up work on a Node.js user survey - goal is to launch next week- that asks what version people are on, and, if other than 4, whether they've considered upgrading, where they need help, what the barriers are, etc. This should give us some great guidance on what info / resources we need on the micro site. I'd love to get your input on the questions if you're interested in taking a look.

[Fishrock123]

1. change Stable - For me, this is the confusing one. I actually like @rvagg 's (sort of) suggestion of Next. I get that it's not strictly true, but to me it is descriptive of why someone would use it - to have access to the latest tech and to preview the direction for the upcoming LTS. Unstable probably is even more descriptive, but I wonder if that would actively discourage its use more than we'd like...

I think "Next" would be a very bad name. The "Stable" line is not pre-releases. LTS is actually behind in this regard. (You could call LTS "Previous+Patches".) Treating "Stable" (even remotely) as a pre-release line can do no good for those in the community who will use the latest major.

I get that it's not strictly true, but to me it is descriptive of why someone would use it - to have access to the latest tech and to preview the direction for the upcoming LTS.

I disagree. There are users who will just only use the latest Major release when possible, and we shouldn't diminish those use-cases. (We can probably fish a bunch up if you really need evidence.)

Unstable probably is even more descriptive, but I wonder if that would actively discourage its use more than we'd like...

The stable release branch isn't _un_stable. We are doing our best to make sure we meet backwards compatibility and do not introduce breaking changes or regressions, while allowing useful features to be added that people can actually use without relying on a development version (that would actually be unstable, ala 0.11)

A huge point of Stable is actually to make this point. It's not at all similar to the odd-numbered release's of node's past.

1. what to do with Master - I don't have any thoughts here really (PUNT).

The only real suggestion for the name of releases off of master has been mine: "dev".

[mikeal]

• Stable (Formerly LTS)
• Current (Formerly "Stable")
• Unstable (Currently master)

[mikeal]

Also, we should note that "Stable" is under LTS and link to our LTS policy wherever we reference it.

[Fishrock123]

Won't that be confusing to users who were previously on "Stable"?

[Fishrock123]

@mikeal i.e.

However, I'm not in favour of dropping "LTS" cause we've put so much effort into that and it already resonates with a large section of our user base, particularly at the operations end. It's also being increasingly used for software projects so is becoming more familiar to more users. There's no reason we can't refer to our LTS branch as being stable if we rename what we currently call "Stable", we're restricted in doing this at the moment so we have to find awkward language to describe it.

[mikeal]

Won't that be confusing to users who were previously on "Stable"?

I have yet to meet this person that isn't already confused by how we use Stable ;)

However, I'm not in favour of dropping "LTS" cause we've put so much effort into that and it already resonates with a large section of our user base, particularly at the operations end. It's also being increasingly used for software projects so is becoming more familiar to more users. There's no reason we can't refer to our LTS branch as being stable if we rename what we currently call "Stable", we're restricted in doing this at the moment so we have to find awkward language to describe it.

That's essentially what I'm suggesting that we do. We call the line "Stable" and rename "Current" and note where we reference Stable that the line is under LTS and link to the LTS policy.

[Fishrock123]

• Stable (Formerly LTS)

I'm confused? You said this above.

and note where we reference Stable that the line is under LTS and link to the LTS policy.

Shouldn't we just refrain from calling anything by "stable" then?

[mikeal]

Sorry, this is confusing because we're contending with prior names and current names. How bout this:

• Stable (currently the v4 branch releases) // in the messaging we note that this line is under our LTS plan.
• Current (currently the v5 branch)
• Unstable (master branch releases)

[Fishrock123]

• Stable (currently the v4 branch releases) // in the messaging we note that this line is under our LTS plan.

I'm going to say we go with @rvagg original plan on this and just call this line LTS. As far as I can tell, "stable" is used for either the equivalent of our LTS or Current line in varying projects and everyone has their own conception of what it means, so we should just drop it altogether in favor of names that are more descriptive, which Current and LTS are.

[mikeal]

We're getting a lot of input from people doing the messaging and marketing of these lines that this isn't working. These people tend to have a greater competency around messaging and marketing than we do. We aren't talking about changing any actual policies or technical work, we're talking about messaging and marketing and I think that it would be appropriate to lean on people with that competency.

"We put a lot into this so let's not change it" doesn't resonate very much with me because the people actually "on the ground" would prefer that we change it. I DO NOT think that we should stop talking about LTS or including LTS in the messaging of the lines under LTS, and neither do the people in messaging and marketing, they just think that the name of the individual release lines confuses the LTS messaging and hurts it and that the best course of action is to change it.

[mjsalinger]

From someone on the ground, I think LTS conveys far more meaning than stable. To me, stable is what I expect a normal release of any software to be. LTS conveys something above and beyond stable to the enterprise community. I think calling an LTS branch 'stable' will diminish its impact in the eyes of enterprise users, even if you link it to LTS docs. I would suggest that keeping the LTS label has a benefit of conveying reliability beyond stable to enterprise users.

I would propose:

• LTS (current v4 branch)
• Current (v5)
• Dev (master)

[mikeal]

The marketing team did a survey recently. From what I recall there didn't actually seem to be a lot of confusion about "LTS" so I think we're good sticking with that label.

I would like to move v5's channel, what we have been calling "Stable" to "Current." Any objections?

[rvagg]

Yeah, I'm not particularly a fan of "Current" (although I'm not a fan of "Stable" either). A change of this type needs buy-in from a broader group than just LTS so if you really want it changed @mikeal then you're probably going to have to wade in to nodejs/node to discuss it. Maybe open a PR to change the wording on README.md as an opener.

[mikeal]

Maybe we can hand this off to @julianduque or @TheAlphaNerd since they are on interacting with the marketing committee and will have access to the relevant survey data.

[julianduque]

@mikeal agree, will ask tomorrow on the marketing committee call and see if we can come up with better labels for the v5 branch, it seems from this thread that we are happy with LTS the way it is.

And personally I prefer to call the master branch Dev or Development rather than Unstable

[rvagg]

@julianduque note that we also have this in play to consider: https://github.com/nodejs/node/issues/4856 I'm going to get back to that asap and resolve it to make something happen but naming is the major blocker there to be resolved.

Just please don't let the Marketing Committee think that they are being given the ability to come up with the name for this or it'll end in tears. There are way more stakeholders involved and we ultimately need to convince the collaborator base that a change is good.

[jasnell]

+1 to what @rvagg is saying here. We are asking the marketing committee for input, not a decision.

[julianduque]

Understood @rvagg :ok_hand:

[natevw]

I think I hit this issue today: http://stackoverflow.com/questions/37532655/why-is-node-js-v4-4-5-recommended-over-v6-2-0-for-most-users

I.e. why is v4 still recommended as the LTS release, if v6 is also available and also a LTS release? If the homepage at one point offered both v4 and v5 that would have made sense. But now it's offering me two LTS releases…why would I choose the previous LTS over the current one??!

[jasnell]

v6 is not LTS yet. It will not transition to LTS until October. On May 30, 2016 12:50 PM, "Nathan Vander Wilt" notifications@github.com wrote:

I think I hit this issue today: http://stackoverflow.com/questions/37532655/why-is-node-js-v4-4-5-recommended-over-v6-2-0-for-most-users i.e. why is v4 still recommended as the LTS release, if v6 is also available and also a LTS release? If the homepage at one point offered both v4 and v5 that would have made sense. But now it's offering me two LTS releases…why would I choose the previous LTS over the current one??!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodejs/LTS/issues/63#issuecomment-222546678, or mute the thread https://github.com/notifications/unsubscribe/AAa2efs1AW6rCtTvJqnhLDaZJSE6-F0Sks5qGz-BgaJpZM4Gzz_l .

[natevw]

@jasnell Meaning what?

As a user I don't want a release that's already in the nursing home, so much as I want one that is eligible for continued care. I just want the version that will give me the least headaches for the longest amount of time.

When Django released version 1.8.0, they said:

Django 1.8 has been designated as Django’s second long-term support release. It will receive security updates for at least three years after its release. Support for the previous LTS, Django 1.4, will end 6 months from the release date of Django 1.8.

They didn't say:

Django 1.8.0 is not recommended for normal users. You see, Django 1.4 is still receiving long term support for a few months, and we haven't cut an official release of Django 1.9 yet either. So if you want long term support, use version 1.4.x which, uh…, will stop being supported in half a year from now. Django 1.8 is a good solid stable release and we promise to support a 1.8.x version for at least three years from now, but the series has not entered its "end of life" phase yet… so we really can't recommend it.

Isn't that what the node.js semver and LTS processes are currently saying? That until 2019-04-01 you will be maintaining a version of node.js that is semver-ishly backwards compatible with the current v6.2.0 download? But we shouldn't use that v6.2.0 because reasons, and instead install a version whose support will run out a full year earlier?

[jasnell]

No, it's not saying that at all. v4 is actively maintained and will be supported until April 2018. v6 is the current release that will transition into LTS in October and will be supported until April 2019. Between now and October, v6 will continue to see new features added while v4 is stable and generally locked down as far as new features are concerned. Both with actively receive security updates throughout their support lifetime. On May 30, 2016 1:22 PM, "Nathan Vander Wilt" notifications@github.com wrote:

@jasnell https://github.com/jasnell Meaning what?

As a user I don't want a release that's already in the nursing home, so much as I want one that is eligible for continued care. I just want the version that will give me the least headaches for the longest amount of time.

When Django released version 1.8.0, they said https://docs.djangoproject.com/en/1.9/releases/1.8/#:

Django 1.8 has been designated as Django’s second long-term support release. It will receive security updates for at least three years after its release. Support for the previous LTS, Django 1.4, will end 6 months from the release date of Django 1.8.

They didn't say:

Django 1.8 is not recommended for normal users. You see, Django 1.4 is still receiving long term support for a few months, and we haven't cut an official release of Django 1.9 yet either. So if you want long term support, use version 1.4 which, uh…, will stop being supported in half a year from now. Django 1.8 is a good solid stable release and we promise to support a 1.8.x version for at least three years from now, but the series has not entered its "end of life" phase yet… so we really can't recommend it.

Isn't that what the node.js semver LTS process is currently saying?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodejs/LTS/issues/63#issuecomment-222550143, or mute the thread https://github.com/notifications/unsubscribe/AAa2eYM48FBicS1Zi3SCb2U1fpWFPkbiks5qG0cMgaJpZM4Gzz_l .

[natevw]

@jasnell As a user, I'm still thrown by this:

will transition into LTS

It looks like in your minds you have three phases:

1. CURRENT: backwards-compatible features (and bug fixes and security patches)
2. ACTIVE LTS: bug fixes (and security patches)
3. MAINTENANCE: only security patches

But I don't care what phase a major version is in, I care what type of version it is.

• [ ] Will it stay compatible with my code?
• [ ] Will it get patches far into the future?

If both are true, why should I be scared away from a version simply because is it only in step 1 of its lifecycle? I'd still call that a "LTS version"; it makes no sense to my mind to be discouraging deployment of that version because it "is not LTS yet".

[jasnell]

For some, the distinction does matter. Particularly, during this first phase there is an increased chance of regressions as semver-minor changes land. For something in active LTS we don't as aggressively land semver-minors. For businesses building production apps that stability matters. It won't matter to everyone, tho which is why we have the parallel current release stream. If that's what works best for your needs, then by all means use that. On May 30, 2016 1:40 PM, "Nathan Vander Wilt" notifications@github.com wrote:

@jasnell https://github.com/jasnell As a user, I'm still thrown by this:

will transition into LTS

It looks like in your minds you have three phases:

1. CURRENT: backwards-compatible features (and bug fixes and security patches)
2. ACTIVE LTS: bug fixes (and security patches)
3. MAINTENANCE: only security patches

But I don't care what phase a major version is in, I care what type of version it is.

• Will it stay compatible with my code?
• Will it get patches far into the future?

If both are true, why should I be scared away from a version because is only in step 1 of its lifecycle? I'd still call that a "LTS version"; it makes no sense to mind mind to be emphasizing that a version "is not LTS yet".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodejs/LTS/issues/63#issuecomment-222552027, or mute the thread https://github.com/notifications/unsubscribe/AAa2eYOZ8_PFjDoqvftOe-IKUnvVD5yuks5qG0smgaJpZM4Gzz_l .

[MylesBorins]

Every even release with get a 30 month support cycle. It is moved into LTS after six months of being current.

When it is lts is will clearly be marked so on the website

[natevw]

@jasnell Okay, that does help explain it. Thanks for your patience!

So I understand then that:

An even-numbered major version is what other projects might call a "long term support" version. However until such a version gets to the ACTIVE LTS phase, there's a much higher risk of accidentally breaking backwards compatibility — a compatibility bug that slips through, a change to some behavior that had never been well-defined, fixing an edge case that some popular library was ill-advisedly betting on, etc.

So when the choice is between two even-numbered branches (as it is now, and distinct from when the newer branch is a short-lived odd-numbered one) the tradeoffs would be:

• Deploy e.g. v4 which is still supported for quite a while yet, and is expected to be kept as stable as practical. But know the support cycle is getting to be halfway over already.
• deploy e.g. v6 which buys me a longer term of "lifecyle remaining", gives me a head start on addressing any breaking changes that were introduced, and gets me access to cool new and upcoming stuff. But know that updating might accidentally cause bad surprises too.

[Fishrock123]

An even-numbered major version is what other projects might call a "long term support" version. However until such a version gets to the ACTIVE LTS phase, there's a much higher risk of accidentally breaking backwards compatibility — a compatibility bug that slips through, a change to some behavior that had never been well-defined, fixing an edge case that some popular library was ill-advisedly betting on, etc.

Correct. (or very close anyways)

This is a compromise between offering as much stability as possible and keeping the platform moving at a good pace for those who want the cutting edge.

[MylesBorins]

Since we've moved on from Stable to Current can we close this?

[jasnell]

+1