-
Notifications
You must be signed in to change notification settings - Fork 29.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LTS: v4.x-staging Branch #3454
Comments
Shouldn't this be just done in the PR branch? I don't see the point... |
What I meant is that PRs should target the v4.x-staging branch, not the v4.x branch |
So what is the purpose of the |
|
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. |
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. |
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. |
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. |
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. |
@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. |
Some background as to the discussion that led to this. We had general agreement on:
In order to support these 2 cases the options seemed to be:
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. |
Process is working rather well so far. Closing this. |
@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 ofv4.x
. Both thev4.x
andv4.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 av4.x
LTS release. Please DO NOT land any commit directly withinv4.x
. Commits will be pulled intov4.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 tov4.x
, please tag the PR using the labellts-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 thev4.x-staging
branch will ensure that we keep thev4.x
branch clean for releases while items are being worked on.The text was updated successfully, but these errors were encountered: