LTS: v4.x-staging Branch

[jasnell]

@nodejs/tsc @nodejs/lts @nodejs/collaborators ... Based on the decision of the LTS WG yesterday, I have just created the v4.x-staging branch off of v4.x. Both the v4.x and v4.x-staging branches are under the oversight of the @nodejs/lts working group.

v4.x-staging will serve as a staging branch for all commits that eventually need to land in a v4.x LTS release. Please DO NOT land any commit directly within v4.x. Commits will be pulled into v4.x only by the person performing the LTS release at the time of the LTS release. When a commit needs to be cherry picked back to v4.x, it MUST land first in v4.x-staging.

In order to make life easier, I would ask that anyone landing a commit into master who feels that the commit may also apply to v4.x, please tag the PR using the label lts-watch-v4.x. This will help us to identify the fixes that need to be picked back. If backporting of the commit is required, doing so against the v4.x-staging branch will ensure that we keep the v4.x branch clean for releases while items are being worked on.

[Fishrock123]

If backporting of the commit is required, doing so against the v4.x-staging branch will ensure that we keep the v4.x branch clean for releases while items are being worked on.

Shouldn't this be just done in the PR branch? I don't see the point...

[jasnell]

What I meant is that PRs should target the v4.x-staging branch, not the v4.x branch

[mscdex]

So what is the purpose of the v4.x branch then? I'm confused ...

[jasnell]

v4.x is for actually cutting the releases. For instance, suppose we land a bunch of commits one week but we're not quite ready for a new LTS release with those items (they're all relatively minor things), but then we get a major security issue that pops up and we need to spin up a new LTS release to cover that. We want to be able to drop that security fix into v4.x and release a new version that contains ONLY the fix for that release, giving us the flexibility to push the other less important items to a different release by not landing them in v4.x right away. It's a bit roundabout and different from the way master and the other stable branches work, but it makes for a much more stable and predictable LTS release. (Essentially, for the folks who really really care about LTS stability, the ability to limit security fix releases to only the security issue that's being addressed makes life much much easier). @mhdawson ... care to expand on that thought a bit?

[Fishrock123]

I don't really think that is actually worthwhile, since anything that lands here is guaranteed to be as stable as anything else really.

The notion of not wanting "regular" fixes confuses and worries me.

[jasnell]

@rvagg @mhdawson

[jasnell]

I didn't say anything about not wanting "regular" fixes. What I said is that the LTS WG wants to have the freedom to decide for itself what commits land and when in specific releases as well as have the ability to quickly spin out LTS releases that include only a specific set of commits. In other words, this is the LTS WG specifically deciding against using the same train model as master and stable. v4.x-staging acts as a buffer, allowing commits to be landed in preparation for going out in a future LTS release but allowing the LTS WG to decide exactly when that happens and in what order.

[jasnell]

That said, the LTS WG is still working out the exact process that's going to be best for managing LTS releases/branches long term so at this point, treat this as an experimental exercise while the LTS WG works on figuring out the best practices.

[bnoordhuis]

I kind of understand where @jasnell is coming from but if you have a delta between v4.x and v4.x-staging, there is room for bugs when you cherry-pick into the v4.x branch. I'm not saying it's a bad idea per se, just pointing out that it has issues of its own.

[mikeal]

Whatever you decide here, please write up these things you want the LTS WG to have ownership over and send a PR to the WORKING_GROUPS list as a charter so that the Core TC can ratify it. Right now this WG is technically unchartered so all of these rights still fall under the main contributorship, TC and release groups.

[jasnell]

@bnoordhuis ... yep. on the LTS WG discussion yesterday, it was recognized that this isn't a perfect solution... it just seemed the least messy. I'm sure we'll continue to tweak the process more as we go.

[mhdawson]

Some background as to the discussion that led to this. We had general agreement on:

1. Except in exception cases, PRs brought into LTS should have been part of a regular release already
2. For security fixes were we don't follow 1), to contain risk we'll make the release contain only the specific security fix as opposed to anything else that may be candidates.

In order to support these 2 cases the options seemed to be:

1. Continually pull into the LTS branch. When we need to make a release branch at the point were on PRs that have been in a release are included or the last release in the case of a security release.
2. Continually pull into the v4.x-staging branch and then cherry pick across to master when we make a release.

There are problems with both, but the agreement was that the second option was preferrable as the mess would be in the staging branch as opposed to the main LTS branch.

[jasnell]

Process is working rather well so far. Closing this.