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 > > > > > >
