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