Discuss possibility of adjusting LTS schedule for better alignment with V8 schedule #62
Comments
|
I'm fine with this. |
|
What would be helpful is a sense of the importance/value of what additional functionality we'd get. This would help to explain the benefit of what we are getting versus the tradeoff of a delayed V6 and a shorter runway to LTS rollover. |
|
Let me explain the motivation: I want the release schedules for Node.js LTS and V8 to be better aligned. I want the V8 release to be a bit more current. If you work backwards from the LTS release schedule to the version of V8 to be picked by the stable in April, that would happen to be V8 4.9 as it goes stable in March (approximately). Feature freezes happen even earlier, and would be around the December-ish timeframe. This is a bit too out of date, and I don't think there is a good reason for it. Concrete benefits of realigning the schedule would be:
I do get the need for the runway between stable and LTS. I don't think the specifics make sense, especially now that we have experience of the first LTS behind us. We had a much shorter runway for the Argon LTS, and it ended up working really well. I am not sure where the 6-months number came from, and I don't think it still makes sense. The runway needs to be long enough to let the module ecosystem catch up, but no longer. A 4-month, or even a 3-month, runway would make a lot more sense, and give us a more current version of V8 in the LTS. |
|
How are we getting 2 months? By my calculations, the Chrome team have been hitting a 7 week (exact) average when taken over the last 4 releases which would put a V8 5.0 at the 26th of April. I think we've maintained in the past that we would be a little flexible around release times, like we were for v5, if it helps us line up with V8 better, if we were still able to hit April then that's probably acceptable (Ubuntu always does late in the month for their releases even though they are tagged with that month). We'd probably need a cut-off though so we're not waiting for a V8 that may end up being delayed. If we're talking pushing back beyond April then the reasoning seems very arbitrary to me. What happens during the next LTS cycle? Do we shorten to 3 months because it fits better with V8? Sorry to be a thorn @ofrobots, I know you're not a fan of the long runways we have for this now but:
This is an arbitrary measure that you could make about any V8 version. You could use this argument to suggest we shouldn't cut v6 until October next year or even that we ship an LTS every 6 months. We have to find a compromise point somewhere and be able to stick to it.
Equally arbitrary that you can make about any V8 version (almost any version), this is still an argument for "the later the better".
This sucks the most, but there's really not much we can do about it while the V8 team continues to ignore the importance of a stable C++ API (and ABI), this is at the core of the compromises we have to make with V8 and I really wish we could do something about this but our hands are tied right now and delaying v6 isn't going to have a material impact on this because it's actually the discrepancy between our 6-month cycle and V8's 6-week cycle that's the problem. My hope is that we can work to one or more of the following scenarios:
Again, I am genuinely sorry to be a negative voice on this but there's nothing here that negates any of our original reasoning for choosing the time-frames that we did for the LTS schedule. It's so critical that we get LTS right and ensure it's stable, solid and and well tested. LTS is for users with very long-term perspectives and we need to be equally long-term in the way we plan for it. @ofrobots: if V8 feature support is critical for Google Cloud, have you considered switching to Stable releases instead? |
That is not what I am arguing at all. I agree completely that we have to find a compromise. I am just questioning where the 6-month number came from and whether it makes sense. A shorter runway would be better for the Node ecosystem. You cannot argue that a 6-month runway is essential. If that was truly the case, Node.js 4 LTS would not have been as successful as it has been, with a much shorter runway.
We figure out what the right runway length is and stick to it for each cycle. We have the experience from the Argon LTS behind us. Let's use it to figure out the cadence going forward.
The length of the runway has more to do how frequently a LTS release comes out and less to do with whether LTS has V8 4.9 or V8 5.1. We are asking the Node.js module ecosystem to react to the API changes once a year (if they want to keep up to date with LTS only) or twice (if they want stable and LTS). Whether they are adapting to V8 4.9 or V8 5.1 isn't as relevant.
I agree completely. Let's get LTS right. |
|
OpenSSL 1.1.0 release timing may be relevant to this discussion nodejs/node#4270 |
|
There seems to be an implied cycle beyond the standard 6ish week cycle that we don't entirely have visibility into. Some kind of planning and stabilization of larger changes in the code that spans beyond the release cycles we see that would be good to line up with. However, I've never seen anything, publicly, that would give us visibility in to what this is and how to plan around it or track it. |
|
Unfortunately I've let this slip a week and my memory of the CTC meeting discussion isn't as clear. I haven't published the audio yet and the minutes are cut short because Chris had to hop off the call and he was the only one taking notes. I believe the general agreement was that we would not be making any changes to the LTS / Release Schedule in this next iteration but we are open to stretching up into the first week of May if need be to take in V8 5.0. Does anyone want to add anything else to this from their recollection of the discussion? |
|
Sounds correct to me.
|
|
The only point that I would like to add is that it would be good to have a bit more predictability on whether Node v6 will ship with v8 v5 or not. NAN will need to be updated and other parts of the ecosystem might be affected by that decision. Right now what I gather is that there is no clear commitment from v8 to hit a specific date for hitting stable. Making that decision at the end of April is not ideal IMO. Can v8 give us an ETA for hitting stable, by an earlier date? |
|
Also what I understood as well. |
|
Closing per WG decision |
@nodejs/lts ... At Node.js Interactive, @ofrobots asked if we could explore the possibility of adjusting the LTS runway to achieve better alignment with the V8 stable schedule. For instance, V8 4.9 will be going into feature freeze after this next week, because Node v6 will be cut in April, v4.9 would be the version of V8 that we ship in v6 and ultimately in the next LTS when v6 rolls over next October. Therefore, any semver-major or breaking changes in V8 would have to land by December 18th, 2015 in order to make it into v6 LTS. However, if we shifted our stable release cycle by two months to ship v6 in June, the V8 team would have more time to get in the additional major fixes they would like to get landed before the next LTS rollover in October. Doing so would mean (a) adjusting our stable release cycle and (b) shortening our LTS runway from six months to four months. Obviously this is something that we would need to consider very carefully.
/cc @nodejs/ctc
The text was updated successfully, but these errors were encountered: