Introduce staging branch for stable release streams

[MylesBorins]

Having done quite a bit of work with v4.x and v4.x-staging I can first hand claim that having the staging branch has made life much easier when it comes to release time.

I'd like to propose using a staging branch workflow for our stable release streams. This could be started once v6 is officially released.

Benefits:

• Land code when delta is closest to zero
• Allows for nightly build off staging
• Easier to automate testing prior to release
• Catch problems early, not the day before a release

Problems:

• v4.x-staging branch has generally not been treated as sacred. If the branch is going to be rebased against v4.x we will need to be ready to handle conflicts both in the branch and in other peoples remotes

/cc @nodejs/ctc

[jasnell]

+1 to this. @nodejs/ctc ... I'd very much like to quickly get the CTC's thoughts on this on today's call.

[Fishrock123]

Sorry - as I discussed in the CTC meeting, I'm not seeing where this has any benefits over the current master->stable situation. master is essentially the staging for the stable.

[MylesBorins]

@Fishrock123 the biggest difference I would see between master and a staging branch would be the lack of semver major changes.

Doing the latest v5 release there were multiple commits that required a bit of extra work to get them to backport properly as they had diverged enough from the v5 stream.

In reality this is likely more an introduction of formalized process and an expectation that things are backported in a timely fashion. If there had not been so many conflicts it would have likely taken less than an hour to put together the proposal rather than half a day (spread across multiple days).

[MylesBorins]

Another advantage would be in limiting the delta in the process between LTS and Stable. While it is true that LTS does require an extra formality (specifically that things live on v5.x for at least a week), should we really have that much of a different process between the two?

If this process is handled correctly it should allow us to distribute some of potentially time sucking work out of the release process, and also offers the ability for us to know that things are not going to land much sooner than the day before a release.

[jasnell]

The point is that master should not necessarily be the staging for stable. As we have seen with things like the recent regressions caused by the path performance updates, and as evidenced by the difficulty in separating out the semver-minor and patches that shouldn't land in v5.x, having a separate staging branch would likely make things significantly easier overall for folks doing the releases.

Also keep in mind that @thealphanerd has been doing a significant amount of the heavy lifting on many of these releases lately, having done most of the v4 releases and a handful of v5 releases. If he's arguing that having the staging branch for stable would make it easier, I don't think we should discount it.

[MylesBorins]

Another one to add to the list... we currently treat v5.x as sacred.

For this weeks release I had wanted to do a patch release, 6d9c0c9 is already sitting on v5.x though. We currently have no option aside from releasing a semver-minor release now... It is my own fault for having landed that commit... but the backport was originally asked for two weeks ago with the hope it would land last week.

If there was a staging branch we could ignore this commit and rebase.

[Trott]

I am in favor of this. master should correspond to the next major version, not necessarily the current major version.

[jasnell]

I'll note here also that @bnoordhuis expressed a +1 on this also here: #6304 (comment)

[evanlucas]

I'm +1 on this and agree with @Trott

[mhdawson]

I'm +1 and while I also like the idea on its own, one of my main reasons is that the people doing the work are saying it will make their life easier.

[Fishrock123]

the biggest difference I would see between master and a staging branch would be the lack of semver major changes.

Same thing from master to the staging branch though. As far as I can tell the only use for the v4.x-staging branch is to allow buffering for security releases.

Another advantage would be in limiting the delta in the process between LTS and Stable. While it is true that LTS does require an extra formality (specifically that things live on v5.x for at least a week), should we really have that much of a different process between the two?

The difference is, to my knowledge, only posed because the LTS has a guarantee that security releases will be absolutely minimal.

If this process is handled correctly it should allow us to distribute some of potentially time sucking work out of the release process, and also offers the ability for us to know that things are not going to land much sooner than the day before a release.

This is already possible. We (especially @rvagg) often land stuff onto v5.x outside of a direct release.

---

The point is that master should not necessarily be the staging for stable. As we have seen with things like the recent regressions caused by the path performance updates, and as evidenced by the difficulty in separating out the semver-minor and patches that shouldn't land in v5.x, having a separate staging branch would likely make things significantly easier overall for folks doing the releases.

I would like some elaboration on how it would actually make things easier. In my experience of cutting a good chunk of stable releases, the exact same things would happen but we'd end up maintaining two branches fro no particular reason.

---

Another one to add to the list... we currently treat v5.x as sacred.

Not quite like master, I think (know) a bunch of us have force-pushed it here and there. Mostly myself and Rod, who have done the majority of stable releases iirc.

For this weeks release I had wanted to do a patch release,

This isn't really the mentality Stable was built around though. It is designed to ship minors of they are, since we ensure with a high level of detail they are roughly as safe as patches.

---

In general, I'm not very interested in having additional burden on the Stable release process. Not at all in favor of this.