Alright Duo, you've convinced me to continue with the branch-x.y strategy for the 2.3.0 release line. I strongly believe that in order to get to a more frequent minor release cadence, we'll want to make the process change that I propose, but I agree that there's a lot of work to do for stabilizing the HEAD of a release line. Hopefully this time next year we'll be in a better place for this.
Thanks, Nick On Wed, Mar 4, 2020 at 4:00 PM 张铎(Duo Zhang) <[email protected]> wrote: > Oh missed the last part > > > > IMHO, we already treat master as the "dev complete" > > branch, so what's the benefit of doing so also with branch-2? > > > This is because of our release model. We consider master and 3.0.0. That > exactly matches the semantic versioning, master is for the next major > release line, branch-x is for the next minor release line, and branch-x.x > is for the next patch release. And once you want to cut a major release, > branch it out as branch-x, and once you want to cut a minor release, branch > it out as branch-x.x. > > 张铎(Duo Zhang) <[email protected]> 于2020年3月5日周四 上午7:55写道： > > > > > > > Nick Dimiduk <[email protected]> 于2020年3月5日周四 上午12:44写道： > > > >> > 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. > >> > > But on branch-2.1, I've done about 10 releases. I just checked the issues > > which have fix versions on 2.1.x and moved out unresolved ones and then > > made a release. > > What I can see is that we still had 50+ fixes even for 2.1.9. I do not > > think it is an easy work for a RMr to backport 50+ patches by his/her > > own, plus you need to review maybe hundreds of issues on jira to decide > > whether it should be backported. Your propose is just increasing the work > > of RM... > > > > > 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... > > > >> > >> > 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 > >> > > > >> > > >> > > >
