Discussion: LTS & v5 release planning #3000
Comments
|
#3000, that's gotta be significant for a discussion like this right? |
ChALkeR
added
the
meta
|
👍 #3000 is very easy to remember for as ticket for a new version
LTS is usually just usual release that is lucky enough to happen on special time. Because it should be supported for longer time, one would consider not to hurry to get newer dependencies version and stick to more stable.
Usually LTS are needed for Enterprise users, no need to promote. LTS can be just below other releases or above as on http://www.ubuntu.com/download/desktop |
I can't think of one in release builds. I'd definitely prefer this. (Maybe when switching back and forth it could cause problems when trying to run npm@2 commands on an npm@3 install? cc @zkat?)
Seems like a reasonable plan. Codename probably?
Given the release team is currently me and Rod, I really don't think so. :/ |
We have some fudge time. More so since we started off schedule anyway. I'd say we wait.
Are we sure it will be ready by Nov 1?
Does LTS have a release timeline? I assume they'll want to do an "official" LTS release shortly after the branch enters LTS. But since it'll all built into the branch version, Jenkins should be good on builds/releases, right? Having an lts-release sounds like a good idea. Even if there is a lot of personnel overlap to start. But things will get more complicated as v8 diverges.
Are smoke tests setup for this? |
|
I'd say the transition point to LTS is fairly arbitrary. If we feel it's The cut of v5.x definitely doesn't need to happen at the same time. We have
|
|
And Yes, the process.release should include the codename at least.
|
|
Part of the initial release plan was not to have a major transition immediately to LTS when the next major was released. Done so users would have some transition time. If v8 has no breaking changes then it can probably be shortened. |
|
@rvagg Regarding the v5, we'll need to evaluate if post-mortem metadata needs to be updated. We have a tracking issue for mdb_v8 here: TritonDataCenter/mdb_v8#36. Evaluating this shouldn't be long (I'll probably be able to do that before the end of the week), I just want to avoid another release happening without having the chance to update the post-mortem metadata. |
|
Thankfully @ofrobots updated at least some of it with https://codereview.chromium.org/1308113007, and possibly other changes. Thank you 👍 I'd still like to spend some time running mdb_v8's tests to make sure that we have everything we need. |
|
It is important that from the website its easy to identify and select the right stream, maybe the download page should have an lts, stable and nightly section |
|
At this point I think its reasonable to leave it to @nodejs/lts to decide what to backport, we probably need some tags so that candidates can be identified |
The frontpage also needs some thought. It would be great to still have a big green download button for the stream suitable for "most developers". Which stream should be default, stable or LTS? |
|
We should recommend the current stable, with the LTS as a long-term fallback for those who need it. |
|
added a checkbox for postmortem metadata, thanks for the reminder @misterdjules |
We are totally onboard with this happening. |
npm v3 is significantly slower than v2 in (some|many|most) cases. |
|
I think getting npm@3 into v5 now and letting it improve is a better option than waiting a half-year for v6. |
|
IMO, a performance issue shouldn't hold us back from pickup on npm@3 from Node v5.0. It is npm stable and, if anything, picking it up on Node 5 will help find more edge cases and get them fixed faster. The only thing that should hold us up from pickup npm@3 for Node 5 would be an irreconcilable breaking change. |
|
Maybe not that important but will npm@2 be maintained by npm team as longs as first Node LTS? Might be one reason to favour npm@3 |
|
@ilkkao that's our plan, yes. We'll agreed to at least support it through Node v4's lifetime (not that I would mind if |
|
@rvagg @ofrobots @targos PR submitted against the vee-eight-4.6 branch to update post-mortem metadata: #3057. If further commits land into that branch with changes to the layout of internal data structures, I would like to be notified before the v5.x release so that we can determine if anything needs to be done regarding post-mortem support. If no other commit land into that branch and that branch ends up being what upgrades V8 in master and for the v5.0 release, I believe we're good to go. |
|
@misterdjules We will be picking up more commits from V8 |
|
@nodejs/collaborators as we are heading in to LTS for v4, the bar for commits that land in the v4.x branch will be significantly raised and there will be no semver-minor additions unless absolutely needed (for security fixes for instances). If there are things pending that you think really should go in to v4.x then you should work on getting them merged next week or you'll miss out. |
|
I do have some philosophical issues with going into LTS without cutting a new stable, but I suppose it doesn't matter too much. I don't really want to be holding semver-minor stuff in |
That shouldn't happen. The original plan was to have overlap of stables to allow for module authors to migrate. Has the plan changed since then? |
|
@trevnorris see my first checkbox above:
i.e. the "plan" hasn't changed, it's the compressed timeframe of v4 and v5 that we're dealing with here, we hoped for a v4 in August where we'd have enough time for this to work out just fine but we've left only a month between v4 and potentially cutting a v5, the options as I see them:
My vote is for option 1. Followed by 3. Option 1 could be managed by merging the |
|
Option 1.
|
|
I'm for Option 1 |
When we get to v5.x, will v8 4.6 be gold? |
That was the intention of that option, yes, edited post to reflect that. Also, fwiw, I'm strongly in favour of shipping LTS in "the first week of October", it's important that we set expectations for users that it'll be predictable each year, LTS are our serious releases where we need to at least look like we know how to be adults, it's all about the signal we send. |
|
+1 for option 1 |
|
My worry about option 1 is once v4 reaches LTS we're limited on the number of commits that can be picked. So we'll have a time lapse when features don't reach the public. If this is only a week or two then whatever. But I'd question it if we have to wait a month. |
|
Option 4, wait until V8 4.6 is ready. LTS means it's going to be around for a long time, don't start with obsolete dependencies from the get-go. |
|
I agree with @bnoordhuis, we want to take a V8 for 5 that is as new as possible to reduce the amount of lag we have in our cycle. |
|
In general, it seems better to miss a deadline than to rush something out. Option 4 seems like the best one, and I'd like to think LTS customers would give allocate more points to "patient and better" than "punctual but rushed". Having hanging patches on master when you don't actually know when v5 will come out is less preferable (option 1), but more tolerable than 2 or 3. |
|
From the TSC meeting yesterday (audio) the general consensus was closer to option 1, pending some discussion in Monday's LTS meeting (which others' are welcome to join just as long as it's for constructive purposes and not to bog us down in bikeshedding things that have been previously covered). i.e. the timeframe during October will look something like this:
In between steps 3 and 4 we some options to discuss:
|
|
Checked some things off in the OP with comments. |
|
Checked "Prepare postmortem metadata in new V8 prior to 5.0.0". |
|
Chrome 46 is out so V8 4.6 is now stable. |
|
npm@3 currently having some minor issues with how we test it. #3308 (comment) I expect it to be resolved quite soon. |
|
Now that Node.js 4.x uses v8 4.x, It would be awesome if Node v5.x was to use v8 v5.x 😆 |
|
Moving on to #3397, thanks all! |
We are approaching October where we've committed to kicking off our first LTS where, according to the LTS plan:
We really wanted to hit October to have that be our LTS timing every year.
There are some things we need to figure out for this, some of which are @nodejs/lts topics but are worth opening up discussion on:
v5.x? We've put ourselves in an awkward position having jumped on 4.5 forv4.xbecause we're not likely to see a stable V8 until at least mid-October. Throughout this year, the V8 team have averaged 45 days between releases, if they hit the average then we'd land at October 15th. If they did it their quickest then we might get the 6th of October, with the latest being the 3rd of November. Do we just keepmasterin a holding state until we have successfully integrated a stable 4.6? Perhaps this is a good chance for us to begin promoting an initial nightly / canary strategy?masterand ourv5.xbranch?process.release, maybeprocess.release.lts: '201510'orprocess.release.lts: 'codename'. If we do this, then do we ensure we cut an actual release in the "first week of October" just to make sure we have this done?5at the front? Ideally, users will be self-selecting and would end up with the kind of release suited to them, perhaps we need to outline on the front page of the website and/or on the download page why you would choose LTS over Stable?What else?
The text was updated successfully, but these errors were encountered: