Perhaps on your last point, regarding patch releases, that we can branch off the previous release tag on demand at that point. We would get the benefits of fewer maintenance branches overall in the normal case, yet have the flexibility to make one should we decide to fix a release by making a new patch release as opposed to a new minor release.
On Tue, Mar 3, 2020 at 10:45 AM Nick Dimiduk <[email protected]> wrote: > Hello, > > What is the current thinking around branch-2 releases? It seems branch-1 is > doing away with "a branch per minor release" strategy. I'm curious if we > should be doing the same on branch-2. To summarize the argument for, as I > see it, > > The pros: > - consistent model for both active release lines. > - encourages more rapid release of new features and the minor releases > that cary them. > - reduces developer overhead managing back ports. > > The cons: > - difficult to "stabilize" a minor release line. > - complex "timing" issues when back-porting new features from master. > - more painful to produce patch releases. > > What other bullets did I miss? > > I am personally in favor of this approach. I think it provides two major > benefits: increase the velocity of feature releases and raise the quality > bar on commits. My counter-arguments to the cons are: > > > difficult to "stabilize" a minor release line > > I argue that this is a process issue, and should be addressed before > patches land. We -- the community -- need to help contributors to validate > their changes while they are in the PR process and sit on feature branches, > before the arrive on the release branch. I argue this should happen before > they hit master as well, but it seems that branch has some tech debit that > needs addressed first. > > > complex "timing" issues when back-porting new features from master. > > We already have this, today, when committers coordinate with a release > manager before merging their patches. > > > more painful to produce patch releases. > > Okay, I don't think this becomes *that* painful, but there is increased > friction. If the community decides the development branch isn't ready for a > release, it becomes the responsibility of the release manager to create a > temporary branch, cherry-pick back any changes that are necessary, tag, and > go. Once the release tag lands, the temporary branch is discarded. In > practice, I think it's not terribly common for new features (that warrant > increasing the minor version number) to come along back-to-back in close > succession, such that they cannot be timed into the same minor release. > > Other concerns? > > Thanks, > Nick > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
