Repository navigation
Introduce staging branch for stable release streams #6306
Description
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
Activity
jasnell commentedon Apr 20, 2016
+1 to this. @nodejs/ctc ... I'd very much like to quickly get the CTC's thoughts on this on today's call.
Fishrock123 commentedon Apr 20, 2016
Sorry - as I discussed in the CTC meeting, I'm not seeing where this has any benefits over the current
master->stablesituation.masteris essentially the staging for the stable.MylesBorins commentedon Apr 20, 2016
@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 commentedon Apr 20, 2016
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 commentedon Apr 20, 2016
The point is that
mastershould 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 commentedon Apr 20, 2016
Another one to add to the list... we currently treat
v5.xas sacred.For this weeks release I had wanted to do a patch release, 6d9c0c9 is already sitting on
v5.xthough. 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 commentedon Apr 20, 2016
I am in favor of this.
mastershould correspond to the next major version, not necessarily the current major version.jasnell commentedon Apr 20, 2016
I'll note here also that @bnoordhuis expressed a +1 on this also here: #6304 (comment)
evanlucas commentedon Apr 21, 2016
I'm +1 on this and agree with @Trott
mhdawson commentedon Apr 21, 2016
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 commentedon Apr 24, 2016
Same thing from
masterto the staging branch though. As far as I can tell the only use for thev4.x-stagingbranch is to allow buffering for security releases.The difference is, to my knowledge, only posed because the LTS has a guarantee that security releases will be absolutely minimal.
This is already possible. We (especially @rvagg) often land stuff onto v5.x outside of a direct release.
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.
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.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.
jasonkarns commentedon May 9, 2016
I'd like to point out that the current collaborator guide is slightly misleading as it implies a v6.x-staging branch should exist: https://github.com/nodejs/node/blob/2fee50658fe38bf6eeecb390d056df69f21acbbb/COLLABORATOR_GUIDE.md#how-are-lts-branches-managed
If a v6.x-staging branch is not created, the collaborator guide ought to be updated to accurately reflect the branching strategy.
9 remaining items
Fishrock123 commentedon Aug 18, 2016
@thealphanerd Now that you can re-target PRs, is this even remotely necessary? It doesn't even matter which branch someone targets now.
We should have a backporting guide though I think.
MylesBorins commentedon Aug 18, 2016
@Fishrock123 that doesn't really affect the purpose of staging imho
vX.xbranch is holy. it shouldn't ever be force pushed or rebased..vX.x-stagingis a development branch that can be rebase, force pushed, rev-parsed, or whatever needs to be done to get a release off the ground.While this might not be as neccessary for
Currentas it is forLTS, but I see a ton of value in having a single process being used.jasnell commentedon Aug 18, 2016
+1, the fact that prs can be retargeted does not really impact whether or not we have a staging branch.
Fishrock123 commentedon Aug 23, 2016
The same rule for force-pushing as
masterapplies. ~10 minutes.Will still end up always being done in the release PR, I don't see the benefit and would not like to spend more time & brainpower than already necessary to do releases. :/
evanlucas commentedon Aug 25, 2016
I'm actually +1 on this now. Up until now, I have always just cherry-picked to v6.x before a release. But since backport PRs are targeting the v6.x branch, how do we handle when stuff lands on v6.x that shouldn't go into the next release? I think we should have a v6.x-staging branch now.
jasnell commentedon Aug 25, 2016
Definitely still +1 to a staging branch. Having gone through and done releases with and without, I much prefer the ease of the staging branch.
Fishrock123 commentedon Aug 25, 2016
Could you please elaborate what this stuff is? If a minor lands they we do a minor release. There should not be a problem with that. It is what semver and tests are for.
rvagg commentedon Aug 31, 2016
Note that we don't have a strict policy of only shipping security updates in Current branches, we just ship as usual and include security updates in the mix, unlike on LTS branches. We've left it up to releasers to decide on what to ship and occasionally releasers have chosen to release only a subset of what could be released (e.g. avoiding a semver-minor bump), but the reasons for doing that are not easily defendable, they come down mostly to preference (I say this as someone who has held back semver-minor commits, with not very strong justification). Also, if there are commits on there that you really don't want to ship, then just pull them out, reinsert and force push, I think we've given releasers that kind of ownership of Current branches when they are doing releases.
I'm neither for or against this but I have a preference for the status quo when the justification isn't very compelling.
jasnell commentedon Aug 31, 2016
At this point, the people who have been doing most of the release and backport work have very clearly and repeatedly indicated that having a staging branch for current would be ideal. Given that the cost is minimal and we can always go back to the current plan if it becomes too difficult to manage, I'd say that we should just go ahead with this.
Trott commentedon Sep 6, 2016
CTC voted in favor of this. Removed
ctc-agendalabel, assigned to @thealphanerd.MylesBorins commentedon Sep 6, 2016
I made a new branch v6.x-staging
new backport commits should be targeted at staging. I will go through the documentation and start updating things tomorrow
MylesBorins commentedon Feb 21, 2017
we do this yay!