Discuss possible clarifications to the LTS messaging / labeling #63
Comments
|
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. |
|
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
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). |
|
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.
Another alternative is "Unstable." That would also re-enforce that "Current" is stable enough to use even if the main label isn't "Stable." |
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. |
|
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 :
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. |
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 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.)
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.
The only real suggestion for the name of releases off of |
|
|
Also, we should note that "Stable" is under LTS and link to our LTS policy wherever we reference it. |
|
Won't that be confusing to users who were previously on "Stable"? |
|
@mikeal i.e.
|
I have yet to meet this person that isn't already confused by how we use Stable ;)
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. |
I'm confused? You said this above.
Shouldn't we just refrain from calling anything by "stable" then? |
|
Sorry, this is confusing because we're contending with prior names and current names. How bout this:
|
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. |
|
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. |
|
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:
|
|
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? |
|
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. |
|
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. |
|
@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 |
|
@julianduque note that we also have this in play to consider: nodejs/node#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. |
|
+1 to what @rvagg is saying here. We are asking the marketing committee for input, not a decision. |
|
Understood @rvagg 👌 |
|
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??! |
|
v6 is not LTS yet. It will not transition to LTS until October.
|
|
@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:
They didn't say:
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? |
|
No, it's not saying that at all. v4 is actively maintained and will be
|
|
@jasnell As a user, I'm still thrown by this:
It looks like in your minds you have three phases:
But I don't care what phase a major version is in, I care what type of version it is.
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". |
|
For some, the distinction does matter. Particularly, during this first
|
|
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
|
|
@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:
|
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. |
|
Since we've moved on from Stable to Current can we close this? |
|
+1 |
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.The text was updated successfully, but these errors were encountered: