I think we will probably always have this struggle around the time we cut a new
release branch and then need to decide what changes on develop to also bring to
the release branch. I'm okay with us not including the big cleanup in 1.15
since it is not something we plan on backporting to other support branches and
if we had cut the 1.15 release branch right before this change, I don't think
we would have approved it to be back ported to the 1.15 release branch.
I share Owen's concern that not including it might case extra work in resolving
conflicts in every change to develop after it that we also want to include in
1.15. We will not know if this is true until we try cherry-picking those
revisions. So I'm unsure what the best way of not including it is. I'm okay
with us cutting the branch from the revision before the big commit and then
working through the list of commits after it and deciding which need to be in
the 1.15 release.
________________________________
From: Alexander Murmann <amurm...@vmware.com>
Sent: Wednesday, January 26, 2022 7:21 AM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: Proposal: Cut 1.15 release branch from SHA
8f7193c827ee3198ae374101221c02039c70a561
Owen, I really appreciate your point about the increased cost of backports by
the branches diverging like this. I do wonder how high the cost will be in
practice, given that AFAIK most of these changes limit themselves to a single
line.
________________________________
From: Owen Nichols <onich...@vmware.com>
Sent: Tuesday, January 25, 2022 20:18
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: Proposal: Cut 1.15 release branch from SHA
8f7193c827ee3198ae374101221c02039c70a561
Even a small change can have subtle but important effects only discovered after
a long time, so leaning on commit-size as a proxy for risk may only serve to
create a false sense of security.
Also to consider, having a large refactor on develop but not support/1.15 will
increase backporting pain, as many cherry-picks will have merge conflicts that
have to be manually "un-refactored".
On 1/25/22, 5:09 PM, "Alexander Murmann" <amurm...@vmware.com> wrote:
Hi everyone,
Last week we discussed to cut the 1.15 release branch. I would like to
propose that we cut the branch from last week's SHA
8f7193c827ee3198ae374101221c02039c70a561. The following commit is a very large
refactor. Nothing obvious seems wrong with that change, but given that we
frequently only discover very subtle, but important changes to Geode after a
long time, I think that this would allow us to reduce some risk for 1.15 and
its future users and give this large change some time to proof itself on the
develop branch. I'd love to avoid that work entirely, but am concerned that we
only might find out about problems a few weeks from now or worse, after we
shipped.
Another option might be to branch from head and revert the change on the
release branch. I am uncertain which approach will proof less work.
