How will older v8 releases be maintained?

[mikeal]

This grew out of the discussion we've been having about the release process. While we are all agreed that the next branch will take new versions of v8 on something close to the v8 release cycle we want to limit the v8 updates that land in master while those updates break native modules.

This means that what is in master will end up having a v8 that is not actively supported by the Google v8 team and will need to be maintained by us. We already have to do this for LTS releases so I'm wondering what the plan is for that and how we can easily integrate an "LTS v8" in to master.

[mikeal]

Reference to release process issues nodejs/node#1997 (comment)

[mhdawson]

I don't think I have a clear picture of the question. We will have one version of V8 for each LTS release that is currently supported that we may need to patch in order to fix issues. Is this simply one more v8 version for master or something more than that ?

[mikeal]

Is this simply one more v8 version for master

Correct. I was wondering what the support strategy was. Are we going to have a v8 repository with older lines or just maintain them in the node branches?

[trevnorris]

I've brought this up a couple times and feel like the only response received was "We'll figure it out when we get there."

@bnoordhuis rightfully pointed out that back porting fixes over a dozen releases will take someone very skilled with the V8 code base. Which is someone we probably can't find.

[mikeal]

@trevnorris a dozen! My hope is that there aren't more than 5.

[trevnorris]

@mikeal If LTS is a year and a half, which seems to be the time table expected, and a V8 release every six weeks then we'll be expected to backport across 12 releases.

[mhdawson]

@trevnorris I assume what you mean by backport is that we need to:

• pull the new V8 level into the Node vNext codebase
• apply any floating patches
• resolve any new failures

and this would have to happen every 6 weeks. I assume at any one time there would only be 1 version of v8 for vNext.

[bnoordhuis]

and this would have to happen every 6 weeks

I think it would be more of a continuous thing where someone follows development on v8 master for patches that are bug fixes that should be back-ported.

The six week approach isn't workable because the delta is so big you won't be able to tell the wheat from the chaff. Take the diff between 4.3 and 4.4, it's almost 70k of lines changed. You can't meaningfully work through that.

$ git diff --shortstat branch-heads/4.3..branch-heads/4.4 -- src/ include/
 569 files changed, 40613 insertions(+), 28544 deletions(-)

And to put that 1.5 year support cycle in perspective:

$ git diff --shortstat branch-heads/3.24..branch-heads/4.4 -- src/ include/
 1165 files changed, 504026 insertions(+), 195149 deletions(-)

That's almost 700,000 lines of changes.

[rvagg]

When getting feedback from companies with large deployments, one of them pointed out nodejs/node-v0.x-archive#14384, as they are on 0.12 and are stuck with a "performance regression". They don't want to downgrade to 0.10 and we don't yet have a version of io.js that fixes this regression (3.0 fixes it but isn't out yet). This is a great example of the kind of problems we're in for maintaining a version of V8 for an extended period of time. If we cut an LTS and it turns out that it has a major performance flaw, then we're stuck with that unless we can fix it ourselves.

Since the V8 team move on in their 6-week cycle and have no reason to care about older versions, I suggest that we consider maintaining our own fork of V8 that's timed for each LTS such that we effectively take over releases of V8 at that point from our own repository and for our own consumption.

Beyond that, we either need to find expertise and willingness within the LTS group or within the Node community to help maintain it and/or we need to convince one or more of the companies supporting and/or relying on LTS releases to invest in paid expertise to do this. Maintaining an old V8 is going to be some of the most unglamorous and thankless work to be done but we need to make sure this happens.

I don't know how complex a fix would be for nodejs/node-v0.x-archive#14384 for 0.12 or 2.x's versions of V8 but for the purpose of our LTS releases I think that this would be considered a bug that we'd need to fix (although, if we take that policy then are we on the hook to fix this one for 0.12 given it'll be LTS for a while?).

[bnoordhuis]

Do we have a concrete plan yet? v4 is shipping V8 4.5 and that's going to be abandoned by upstream in less than a month.

[rvagg]

no

[MylesBorins]

closing in lieu of #111