Discussion: LTS & v5 release planning

[rvagg]

We are approaching October where we've committed to kicking off our first LTS where, according to the LTS plan:

... with the first LTS release cut during the first week of October, 2015

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:

• Do we wait for the next V8 before branching and releasing v5.x? We've put ourselves in an awkward position having jumped on 4.5 for v4.x because 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 keep master in 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?
  • (Sounds like we are) ~ @Fishrock123
• Is there any good reason not to bump npm to v3 in master and our v5.x branch?
  • (LTS group agrees npm@3 is a good idea) ~ @Fishrock123
• We need a codename for the release, there is some discussion here with the current plan for the LTS WG to come up with a shortlist and then give the collaborators the chance to vote on their preferred option. It's looking likely that we'll be picking something off the periodic table. (Please don't bikeshed this topic in this issue, take it to First LTS Release 'codename' Release#26 if you feel it's that important).
  • (See: src: add process.release.lts property & LTS CODENAME VOTING #3212) ~ @Fishrock123
• Do we bake something into the LTS binaries to signify that they are LTS? I can't recall where this discussion was but we had talked briefly about possibly putting something in process.release, maybe process.release.lts: '201510' or process.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?
  • (See: src: add process.release.lts property & LTS CODENAME VOTING #3212) ~ @Fishrock123
• How exactly do we transition to an LTS release process? Do we just throw it to @nodejs/lts to figure out exactly how to determine what to cherry-pick? Do we have a special group, @nodejs/lts-release, separate from @nodejs/release to handle these? Does it matter? Once we have an idea for the number of commits we might be pulling in then we should probably discuss likely release cadence for LTS.
• How do publicise and promote LTS lines? Does @nodejs/website have ideas on how to make this happen when we have something called "LTS" and then start to get new "Stable" releases with a 5 at 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?
• Do we need to prepare a new NAN for V8 4.6? I don't see anything that's obviously breaking but it'd be good to have @nodejs/addon-api tuned in to the v5 timeline.
• Prepare postmortem metadata in new V8 prior to 5.0.0, tracking @ Update mdb_v8 for V8 4.6.x TritonDataCenter/mdb_v8#36

What else?

[rvagg]

#3000, that's gotta be significant for a discussion like this right?

[paulvi]

👍 #3000 is very easy to remember for as ticket for a new version

How exactly do we transition to an LTS release process?

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.

How do publicise and promote LTS lines?

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

[Fishrock123]

Is there any good reason not to bump npm to v3 in master and our v5.x branch?

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?)

Do we bake something into the LTS binaries to signify that they are LTS

Seems like a reasonable plan. Codename probably?

How exactly do we transition to an LTS release process? ... Does it matter?

Given the release team is currently me and Rod, I really don't think so. :/

[trevnorris]

Do we wait for the next V8 before branching and releasing v5.x?

We have some fudge time. More so since we started off schedule anyway. I'd say we wait.

Is there any good reason not to bump npm to v3 in master and our v5.x branch?

Are we sure it will be ready by Nov 1?

How exactly do we transition to an LTS release process?

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.

Do we need to prepare a new NAN for V8 4.6?

Are smoke tests setup for this?

[jasnell]

I'd say the transition point to LTS is fairly arbitrary. If we feel it's
ready by the end of the first week in October, let's do it.

The cut of v5.x definitely doesn't need to happen at the same time. We have
wiggle room there. Let's wait until later in October and land the V8
update. If npm3 lands after I have no problem cherry picking it back from
master.
Btw, I ought to have an updated citgm for better smoke testing by the
second week of October.
On Sep 22, 2015 9:51 AM, "Trevor Norris" notifications@github.com wrote:

Do we wait for the next V8 before branching and releasing v5.x?

We have some fudge time. More so since we started off schedule anyway. I'd
say we wait.

Is there any good reason not to bump npm to v3 in master and our v5.x
branch?

Are we sure it will be ready by Nov 1?

How exactly do we transition to an LTS release process?

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.

Do we need to prepare a new NAN for V8 4.6?

Are smoke tests setup for this?

—
Reply to this email directly or view it on GitHub
#3000 (comment).

[jasnell]

And Yes, the process.release should include the codename at least.
On Sep 22, 2015 1:44 AM, "Rod Vagg" notifications@github.com wrote:

We are approaching October where we've committed to kicking off our first
LTS where, according to the LTS plan:

... with the first LTS release cut during the first week of October, 2015
https://github.com/nodejs/LTS/

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 https://github.com/orgs/nodejs/teams/lts topics but are
worth opening up discussion on:

• Do we wait for the next V8 before branching and releasing v5.x?
  We've put ourselves in an awkward position having jumped on 4.5 for
  v4.x because 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 keep master in 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?
• Is there any good reason not to bump npm to v3 in master and our v5.x
  branch?
• We need a codename for the release, there is some discussion here
  First LTS Release 'codename' Release#26 with the current plan for
  the LTS WG to come up with a shortlist and then give the collaborators the
  chance to vote on their preferred option. It's looking likely that we'll be
  picking something off the periodic table. (Please don't bikeshed this topic
  in this issue, take it to First LTS Release 'codename' Release#26
  First LTS Release 'codename' Release#26 if you feel it's that
  important).
• Do we bake something into the LTS binaries to signify that they are
  LTS? I can't recall where this discussion was but we had talked briefly
  about possibly putting something in process.release, maybe process.release.lts:
  '201510' or process.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?
• How exactly do we transition to an LTS release process? Do we just
  throw it to @nodejs/lts https://github.com/orgs/nodejs/teams/lts to
  figure out exactly how to determine what to cherry-pick? Do we have a
  special group, @nodejs/lts-release, separate from @nodejs/release
  https://github.com/orgs/nodejs/teams/release to handle these? Does
  it matter? Once we have an idea for the number of commits we might be
  pulling in then we should probably discuss likely release cadence for LTS.
• How do publicise and promote LTS lines? Does @nodejs/website
  https://github.com/orgs/nodejs/teams/website have ideas on how to
  make this happen when we have something called "LTS" and then start to get
  new "Stable" releases with a 5 at 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?
• Do we need to prepare a new NAN for V8 4.6? I don't see anything
  https://docs.google.com/document/d/1g8JFi8T_oAE_7uAri7Njtig7fKaPDfotU6huOa1alds
  that's obviously breaking but it'd be good to have @nodejs/addon-api
  https://github.com/orgs/nodejs/teams/addon-api tuned in to the v5
  timeline.

What else?

—
Reply to this email directly or view it on GitHub
#3000.

[trevnorris]

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.

[misterdjules]

@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.

[misterdjules]

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.

[mhdawson]

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

[mhdawson]

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

[phillipj]

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

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?

[Fishrock123]

We should recommend the current stable, with the LTS as a long-term fallback for those who need it.