Node: Planning for v7 and the v6 roll over to LTS

Created on 6 Aug 2016  路  7Comments  路  Source: nodejs/node

@nodejs/collaborators: October will be coming up quick, which means that it is time to start thinking about v7 and the roll over of v6 to LTS. Let's use this issue to begin collecting the todos remaining and other planning for the releases. I will volunteer to shepherd the v7 release.

v7

With that in mind... with the v6.0.0 release, we opted to cut the release branch directly from master. This led to a number of issues because we had several problematic semver-major commits land during the release candidate cycle immediately before the release.

Based on lessons learned from that, what I would _propose_ is that we cut the v7.x branch off master the _first week of September_, and that we begin handling it as a stable branch early, in advance of the release, landing only semver-patch and semver-minor commits. The v7.0.0-RC.1 would be cut from that branch the first week in September, with a new RC each week until the release in October. _Semver-major_ commits would only be pulled into the v7.x branch only with explicit @nodejs/ctc review and approval.

This process will allow us to ensure that v7.x is as stable as possible before the actual release of v7.0.0 in October. This means that any of our pending semver-major PRs that have yet to be resolved would need to be looked at this month.

If there are specific PRs that you feel should be definitely be included in the v7 release, please add them to the 7.0.0 milestone.

Items on the v7.0.0 milestone

v6

For the v6.x roll over into LTS, we need to make sure that all remaining pending issues with the fs module are resolved. For instance, the callback checks have been removed, but we still need to add back in the deprecation warning that indicates that those check will be added later. We also need to complete the rollback of the fs.realpath() implementation. _Ideally_, I think we should target landing those changes by mid-September in order to give us plenty of time to evaluate and test before the LTS rollover in October.

LTS

One thing to remember is that once v6 does roll over into LTS, we will have _2_ active LTS lines (v4 and v6). LTS support for v0.10 expires in October, with v0.12 expiring in December. 2 active LTS lines means double the work backporting commits and keeping things straight. @TheAlphaNerd has done an absolutely amazing job at keeping v4 on track but we'll need others to help step up to help manage the second active LTS branch (I'll be helping as much as possible).

meta

Most helpful comment

@TheAlphaNerd has done an absolutely amazing job at keeping v4 on track

No doubt about it 馃憦 馃憦 馃憦

All 7 comments

What would be version of V8 rolled out in Node.js v7.0.0? cc @nodejs/v8

@TheAlphaNerd has done an absolutely amazing job at keeping v4 on track

No doubt about it 馃憦 馃憦 馃憦

@thefourtheye fwiw, #7904 would be a discussion issue for the V8 version in Node v7

The v7.0.0-RC.1 would be cut from that branch the first week in September, with a new RC each week until the release in October.

This means patches will continue to be applied to the v7.0.0 release for the month of September, after RC.1 is cut, right? If so, can we please not call it an RC, since it's not an actual candidate for release? Better (IMO) options:

  • v7.0.0-beta.1
  • v7.0.0-b1
  • v7.0.0-b.1
  • v7.0.0-pre1
  • v7.0.0-pre.1

Additionally, would we consider picking a target date for a release of a true release candidate? That is: "Except for the version changing, this is exactly what will be released in X days unless significant bugs are found. Please test it. Unless we need to fix a significant defect, we won't introduce new code." Maybe a week before the release? Or if that just isn't tolerable for whatever reason, maybe three days?

People are likely to ignore the non-RC "RC" releases throughout September--why pay attention to these releases that aren't actually any different from the nightlies?--but if we plunk down a true RC at some point, people _might_ be more motivated to test it. Like, "Hey, test this with your stuff, because this is totally going to be v7.0.0 if we don't find big problems. Update your code, or tell us we have a glaring defect to fix."

Not sure how much extra work this would create for the folks doing the releases...

Quick update for all @nodejs/collaborators ... especially @nodejs/ctc ... I plan to cut the v7.x branch off master on _Monday September 12th_ unless there are objections. That means that all semver-major commits that are intended for v7.0.0 should be in by then. I plan to start cutting v7.0.0-beta releases each week after the branch is cut with an eye towards a late-October release to accommodate the pending v8 54 update.

As of now, there are 9 open PRs in the 7.0.0 milestone that are labeled semver-major. https://github.com/nodejs/node/issues?utf8=%E2%9C%93&q=is%3Aopen%20milestone%3A7.0.0%20label%3Asemver-major

@nodejs/collaborators : Another heads up... v7.x branch will be cut the morning of Monday September 12th and I will start producing weekly beta builds. Please get your semver-majors in before that. After the branch is cut the bar for landing semver-major's is going to be pretty high.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

VanCoding picture VanCoding  路  204Comments

substack picture substack  路  878Comments

yury-s picture yury-s  路  89Comments

egoroof picture egoroof  路  90Comments

speakeasypuncture picture speakeasypuncture  路  152Comments