I think someone saying they are willing to act as release manager for a maintenance release would be sufficient to justify doing a maintenance release.
I also like this proposal. On Tue, Mar 3, 2020, 16:22 Bharath Vissapragada <[email protected]> wrote: > 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 > > >
