Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Planning for v7 and the v6 roll over to LTS #7991
@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.
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
This process will allow us to ensure that v7.x is as stable as possible before the actual release of
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
For the v6.x roll over into LTS, we need to make sure that all remaining pending issues with the
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).
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:
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.