> What will be the criterion for a new patch release with this model? >From my previous RM experience, I really liked the process of the RM coming around once/month, check the branch for activity, and if there's enough fixes to justify, do a release. In my proposed model, that monthly cadence doesn't change. The RM would scan Jira for the release line branch (branch-2, in this case), looking for bug fixes. They create a "patch release branch" from the minor version's last release tag, queue up anything that looks relevant onto a temporary "patch release branch". They cut the RC from that branch. When an RC is accepted, the permanent tag is pushed and the "patch release branch" is deleted.
> Stabilizing a branch with lots of new features is just human-impossible. Well, not human-impossible, but I agree that it is a lot of work. We do this ahead of every minor release, so what changes? Isn't it better to do the stabilization on branch-2 (or master) than after a minor release line branch is cut? Isn't it better to do the stabilization on a feature branch of that big new feature, before it gets merged? > 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. Nothing I've proposed here is against or incompatible with semantic versioning. > 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. I'm not at all suggesting that branch-2 should end with 2.3. What I'm suggesting is that we shift our mentality of "back-port this patch to branch-2 when it's dev complete" to "back-port this patch to branch-2 when it's production ready." IMHO, we already treat master as the "dev complete" branch, so what's the benefit of doing so also with branch-2? Thanks, Nick On Tue, Mar 3, 2020 at 4:01 PM 张铎(Duo Zhang) <[email protected]> wrote: > 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 > > >
