All your arguments (and counter-arguments) make sense to me. A process question, out of curiosity. What will be the criterion for a new patch release with this model? Would it be determined on a case-by-case basis (discuss, vote..)? For example, we'd want to do a patch release for a critical CVE that affects older 2.x.0 releases.
I agree with Andrew's suggestion to branch off of the release tags on demand. Reduces the maintenance overhead with fewer branches. On Tue, Mar 3, 2020 at 12:12 PM Andrew Purtell <[email protected]> wrote: > 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 >
