OK, so your point is to make minor release line more frequently. Then your proposal is reasonable.
But I still have a bit concern on having more frequent minor releases, as I do not think it is possible to stablize a branch which is very active and keep adding new features, based on the development workflow today. In general, I think we need to change the whole release schedule if we want to do more frequent minor releases, at least major releases should also be more frequent. A possible solution is to follow the jdk pattern, where we make new major releases half a year, but only a small set of them are LTS versions... Thanks. Nick Dimiduk <[email protected]> 于2020年3月11日周三 上午7:43写道： > 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 > > >> > > > > >> > > > >> > > > > > >
