Discussion: Continued LTS of v0.x Stream

[jasnell]

v0.10 and v0.12 are still, by far, the most broadly used node.js versions. While there are lots of great things happening in the io.js stream, it would be a very good idea to continue LTS support on v0.10 and v0.12 as well as continue to cut new LTS releases on the v0.x stream for the foreseeable future -- so long as we have collaborators actively willing to support that stream. This would ensure that those users/customers who are not quite ready to make the jump up will continue to be supported.

The net result is that at some point this year, we should likely expect a v0.14 LTS cut off the joyent/node stream before end of year.

/cc @nodejs/tsc

[mikeal]

why 0.14? there hasn't been a release yet, not even a 0.13 release yet, and I didn't expect to see one prior to the merge being complete.

Also, yes yes yes yes yes on v0.10 LTS being a priority. At the same time, it might be attractive to do 1.x LTS releases to test out the process and tooling because any problems we find would impact less users than a v0.10 release.

[jasnell]

Not a definite, but we should leave the door open for it. Again, it's largely predicated on two factors: (a) having collaborators actively willing to drive it and (b) having existing LTS users/customers who aren't quite ready to make the jump to the newer V8/features yet. For those, it would still be worthwhile being able to deliver key improvements such as the iterative improvements on the Intl support. Doing so does not interfere with any of the master stream efforts or scheduling so the impact is minimal.

[Fishrock123]

We should probably cross-post an issue on io.js and talk about this in Wednesday's TSC meeting.

I think we'd probably be doing disservice by doing a 0.x.0 (0.x feature release). Features should land in the latest stable dev (master) branch. I understand we are still doing both joyent/node and io.js releases until converged, but since we are again "one" project, doing feature releases on a branch effectively two majors ago could get very confusing.

Another very important thing do discuss is how we do the commit porting part of LTS / maintainence. It was decided with an io.js pace of development landing everything in master was most reasonable, and to back port fixes if applicable.
I understand node has traditionally landed everything in the oldest applicable supported branch and merged forward; how would th node folks feel about the io.js way?

[bnoordhuis]

The net result is that at some point this year, we should likely expect a v0.14 LTS cut off the joyent/node stream before end of year.

Serious question: what is there even to release?

[jasnell]

At this point, not much. Like I said, this is largely to keep the window open for it.

[jasnell]

@misterdjules ... would be great to have your thoughts on this.

[misterdjules]

@jasnell Please correct me if I'm wrong, but here's how I understand the original topic of this discussion.

Most users of node use node v0.10.x and v0.12.x. As a result, most users will move from v0.10.x or v0.12.x to the next major release of the converged repository. However, this transition seems scary at least for some users because there would be a discontinuity between the v0.12 branch of joyent/node and the next release from the converged repository.

From one day to the next, some users would go from using node v0.12.x to node v3.x (or whatever version it ends up being) without having the opportunity to run development versions of that release against their code bases and adapt to breaking changes.

One of these breaking changes is the newer version of V8 that will be shipped with the first release from the converged repository. There would probably be other breaking changes as well, even if they're not intentional.

The important idea is that I have the feeling that nobody today really knows what would be the impact on existing users of joyent/node (which represent most users of Node.js) of releasing the next version from the converged repo. At least I don't know that, and some of the users that are concerned by this transition don't know that too. I think that if users are concerned and scared by this transition, it has a negative impact on everyone

I believe there are several ways we can mitigate these concerns, and what @jasnell suggested by having a set of v0.14.x releases is one way of doing that. The goal would not be to release v0.14.x for the sake of it, but as a way to provide a smoother transition. If it doesn't help to achieve that, then let's not do it. Also, the changes that would be shipped in v0.13.x and/or v0.14.x releases could come from either existing/future io.js or joyent/node commits, it doesn't really matter: the end goal would be to make it easier for users to transition.

We could also explore other ideas:

• Documenting clearly, in a way that can be consumed by actual node users and not only collaborators, the breaking changes between node v0.12.x and the next release from the converged repository.
• Reaching out to a representative set of users to understand what changes have the most impact and how to make sure the transition is as smooth as possible. For instance, @Raynos said in Discussion: Soliciting LTS input from Node user community #8 (comment) that "[he] just need[s] a core file analyze tool that works; 100% of the time.". I think that's the type of data/feedback we need and that we currently don't have, or that is at least not in a centralized resource that is known and available to everyone.
• Communicating about the intention and effort to provide the smoothest transition possible. Some of these concerns are also likely to be due to the fact that there hasn't been a lot of communication about how the transition between v0.12.x and the next release from the converged repo will be done. Actively communicating about that, for instance by having a specific section on the nodejs.org website, would probably already help.

What I would suggest is that we start by:

1. Documenting what the breaking changes would be for users switching from v0.12.x to a release from the converged repo.
2. Reaching out to the broadest set of representative users as we can to identify critical concerns on such a migration.

Thoughts?

[bnoordhuis]

Sounds like a reasonable approach to me. How do you plan to get in touch with users?

[mhdawson]

+1, information on the changes and input from users are key to making the right choice

[misterdjules]

@bnoordhuis I imagine that the way we need to reach out to node users will also depends on the list of breaking changes between v0.12.x and the target for the next LTS release to be made from the converged repo. So I would think coming up with that list is the first step.

Then, if we need to reach out to users, I can think of several ways to do that, and there are probably more options:

• Getting help from the Node.js Advisory Board, I think they talked recently about having something like a "Users Working Group". That would be a good example of how that working group could be useful.
• Using Twitter, GitHub and other social platforms.
• Businesses who are members of the Node.js Foundation, the advisory board or of the broader community could reach out personally to their clients/customers/users and report back to the TSC.

That will need some significant amount of preparation and coordination.

[mikeal]

Using Twitter, GitHub and other social platforms.

Once the list of changes is ready ping the Evangelism WG and we'll figure out a plan to best get the word out.

Businesses who are members of the Node.js Foundation, the advisory board or of the broader community could reach out personally to their clients/customers/users and report back to the TSC.

I imagine that by the time we do this release the list of foundation members won't be too huge but we expect this to grow significantly over time to working this in to the process is a great idea. Once the foundation is setup we'll make sure setup some kind of email group to easily reach out to the members.

[misterdjules]

What I would suggest is that we start by:

Documenting what the breaking changes would be for users switching from v0.12.x to a release from the converged repo.

I started doing that here: https://github.com/nodejs/node/wiki/Breaking-changes-between-v0.12-and-next-LTS-release. Should that move to nodejs/LTS' Wiki instead?

I would love to get your feedback and your opinions on how we could make that document better. This is really just a first draft to get the ball rolling.

I took the liberty to create a @nodejs/lts team too so that we can mention people interested in this topic more easily. Let me know if that's not the recommended process.

Once we get enough reviews and we are confident that that document includes a representative list of breaking changes, we can move to step 2:

Reaching out to the broadest set of representative users as we can to identify critical concerns on such a migration.

with that list + other questions that will help us have more data on whether or not a v0.14.x or any other strategy is needed.

@nodejs/lts @nodejs/tsc Thoughts?

[misterdjules]

Closing in favor of #10, but feel free to reopen if you think this issue should stay open.