On Wed, Mar 4, 2020 at 3:56 PM 张铎(Duo Zhang) <[email protected]> wrote:
> Nick Dimiduk <[email protected]> 于2020年3月5日周四 上午12:44写道： > ... > > 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? > > > These are different levels of stablization. Usually if all UTs are fine, we > will let a feature in. This is enough for a contributor. But for a minor > release, we need to run ITBLL several times. That's why it is not a good > idea to do the final stablizing on branch-2. There are only two results, > either you can not stablize the branch as we still pull in new features, or > you block all the backports for a while... > > I see Nick's point but am in favor of a branch for 2.3 for arguments like those made by Duo above. Stabilization is a significant undertaking easily disturbed often obliquely. The stabilizer/RM has a better chance of success if containment as a branch per minor version affords. Stabilizing the tip of a major branch (unless it long-in-the-tooth like branch-1) strikes me as more difficult to achieve especially ongoing. Thanks, S > > > > > 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. > > > But the work for a RM will be increasd dramatically if you still want to > make patch releases. This is not good. Usually we consider a patch release > to be stable after several patch releases, and I think this proposal will > lead to very very few patch releases. Trust me, people are lazy, we are not > a company, all people are volunteers, so do not put too many works on a > single person... > > > > > > 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? > > > OK, I got your point. But for me, production ready means at least you > should use it in production right? A feature is only on master then how do > you make it production ready? No one will use it. So this just means do not > back port anything... > > > > > 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 > > > > > > > > > >
