You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Nick Dimiduk <nd...@apache.org> on 2020/03/03 18:44:56 UTC
[DISCUSS] Branching strategy for ongoing branch-2 releases
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
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by Stack <st...@duboce.net>.
On Wed, Mar 4, 2020 at 3:56 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> Nick Dimiduk <nd...@apache.org> 于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) <pa...@gmail.com>
> > 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 <nd...@apache.org>于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
> > > >
> > >
> >
>
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
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 <nd...@apache.org> 于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) <pa...@gmail.com>
> 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) <pa...@gmail.com> 于2020年3月5日周四 上午7:55写道：
> >
> > >
> > >
> > > Nick Dimiduk <nd...@apache.org> 于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) <pa...@gmail.com>
> > >> 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 <nd...@apache.org>于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
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by Nick Dimiduk <nd...@apache.org>.
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) <pa...@gmail.com> 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) <pa...@gmail.com> 于2020年3月5日周四 上午7:55写道：
>
> >
> >
> > Nick Dimiduk <nd...@apache.org> 于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) <pa...@gmail.com>
> >> 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 <nd...@apache.org>于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
> >> > >
> >> >
> >>
> >
>
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
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) <pa...@gmail.com> 于2020年3月5日周四 上午7:55写道：
>
>
> Nick Dimiduk <nd...@apache.org> 于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) <pa...@gmail.com>
>> 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 <nd...@apache.org>于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
>> > >
>> >
>>
>
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Nick Dimiduk <nd...@apache.org> 于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) <pa...@gmail.com>
> 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 <nd...@apache.org>于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
> > >
> >
>
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by Nick Dimiduk <nd...@apache.org>.
> 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.
> 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?
> 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.
> 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?
Thanks,
Nick
On Tue, Mar 3, 2020 at 4:01 PM 张铎(Duo Zhang) <pa...@gmail.com> 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 <nd...@apache.org>于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
> >
>
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
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 <nd...@apache.org>于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
>
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by Sean Busbey <bu...@apache.org>.
I think someone saying they are willing to act as release manager for a
maintenance release would be sufficient to justify doing a maintenance
release.
I also like this proposal.
On Tue, Mar 3, 2020, 16:22 Bharath Vissapragada <bh...@apache.org> wrote:
> All your arguments (and counter-arguments) make sense to me.
>
> A process question, out of curiosity. What will be the criterion for a new
> patch release with this model? Would it be determined on a case-by-case
> basis (discuss, vote..)? For example, we'd want to do a patch release for a
> critical CVE that affects older 2.x.0 releases.
>
> I agree with Andrew's suggestion to branch off of the release tags on
> demand. Reduces the maintenance overhead with fewer branches.
>
>
> On Tue, Mar 3, 2020 at 12:12 PM Andrew Purtell <ap...@apache.org>
> wrote:
>
> > Perhaps on your last point, regarding patch releases, that we can branch
> > off the previous release tag on demand at that point. We would get the
> > benefits of fewer maintenance branches overall in the normal case, yet
> have
> > the flexibility to make one should we decide to fix a release by making a
> > new patch release as opposed to a new minor release.
> >
> >
> > On Tue, Mar 3, 2020 at 10:45 AM Nick Dimiduk <nd...@apache.org>
> wrote:
> >
> > > 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
> > >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> > - A23, Crosstalk
> >
>
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by Bharath Vissapragada <bh...@apache.org>.
All your arguments (and counter-arguments) make sense to me.
A process question, out of curiosity. What will be the criterion for a new
patch release with this model? Would it be determined on a case-by-case
basis (discuss, vote..)? For example, we'd want to do a patch release for a
critical CVE that affects older 2.x.0 releases.
I agree with Andrew's suggestion to branch off of the release tags on
demand. Reduces the maintenance overhead with fewer branches.
On Tue, Mar 3, 2020 at 12:12 PM Andrew Purtell <ap...@apache.org> wrote:
> Perhaps on your last point, regarding patch releases, that we can branch
> off the previous release tag on demand at that point. We would get the
> benefits of fewer maintenance branches overall in the normal case, yet have
> the flexibility to make one should we decide to fix a release by making a
> new patch release as opposed to a new minor release.
>
>
> On Tue, Mar 3, 2020 at 10:45 AM Nick Dimiduk <nd...@apache.org> wrote:
>
> > 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
> >
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
>
Re: [DISCUSS] Branching strategy for ongoing branch-2 releases
Posted by Andrew Purtell <ap...@apache.org>.
Perhaps on your last point, regarding patch releases, that we can branch
off the previous release tag on demand at that point. We would get the
benefits of fewer maintenance branches overall in the normal case, yet have
the flexibility to make one should we decide to fix a release by making a
new patch release as opposed to a new minor release.
On Tue, Mar 3, 2020 at 10:45 AM Nick Dimiduk <nd...@apache.org> wrote:
> 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
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk