I’m -1 on doing the same on branch-2. Stabilizing a branch with lots of new features is just human-impossible. Even if you run ITBLL for every commit, you may still miss something. Welcome to the distributed system world. And this is also why we use semantic versioning. Major for big incompatible features, minor for almost compatible features, and patch with almost no new features.
IIRC for branch-1, the conclusion is that, new features are not likely to be backported by default, and no one actually take care of branch-1, so to reduce the work for release managers 1.x, we decided to make release directly on branch-1. So for me, if we think 2.3.x will the last branch-2 minor release line, and new features are not expected to be backported to branch-2 by default, then it is OK that we just make release from branch-2. But I do not think this is the truth, people are still discussing how to land the rsgroup changes on branch-2 and think it should be landed for 2.4.x... Thanks. Nick Dimiduk <[email protected]>于2020年3月4日 周三02:45写道： > 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 >
