My opinion:
(1) List out must fix bugs for 1.4 (I don’t think there’s any, but it’s good to
review)
(2) cut the 1.4 release branch and start the stabilization period asap.
Gester
From: Anilkumar Gingade <aging...@vmware.com>
Date: Monday, January 4, 2021 at 7:23 AM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
My recommendation will be:
- Identify, Prioritize, Merge 1.14 related work
- Stabilize. Cut the branch and Stabilize again (to test any new changes added
during first stabilize period)
-Anil.
On 12/18/20, 2:26 PM, "Mark Hanson" <hans...@vmware.com> wrote:
I support the cut on a predetermined date. But I will be ok with the
Stabilize first approach, because I think that having a stable build is a
prerequisite for any time based model. But like all things, this is a smell
that we have to do this... The other thing is that specifying a date or a
window of time in my opinion is crucial to ensuring freshly baked features are
not merged until we cut the release. The window need not be very long a day or
two as an example. With the volume of defects that we need to assess/fix
maintaining control of develop seems important. So I would propose that we
give notice of when we are looking to cut the branch (once we have made
adequate determinations for the defects).
Thanks,
Mark
On 12/18/20, 12:09 PM, "Owen Nichols" <onich...@vmware.com> wrote:
To summarize this thread so far:
@Robert and @Jens seem to favor “cut then stabilize”
@Alexander and @John seem to favor “stabilize then cut”
No one seems to favor “cut on a predetermined date” (at least for 1.14)
@John also made a creative suggestion that maybe 1.14 doesn’t have to
be cut from latest develop…what if we cut it from support/1.13 and then
backport just the redis changes (in parallel with continuing to stabilize
what’s currently on develop into a 1.15 release).
For now let’s try to proceed on the “stabilize then cut” plan. All
committers, please hold off on merging big refactorings or other high-risk
changes to develop until after the branch is cut. Let’s regroup next month and
try to clarify exactly which GEODE Jira tickets we need to focus on to make
sure 1.14 is our best release.
From: Owen Nichols <onich...@vmware.com>
Date: Tuesday, December 1, 2020 at 12:26 PM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
If someone wants to propose a list of must-fix Jira tickets before we
can cut the branch, I see that as a shift from a time-based to feature-based
branch-cut strategy. Might be fun to try?
Given the distributed nature of the Geode community, picking a date and
sticking to it allows decentralized decision-making (each contributor can plan
on their own what they can finish and/or how they can help get develop as
stable as possible by that date).
To answer your question: the current state of develop feels “pretty
good” to me. Knowing that only critical fixes will be allowed onto the branch
once cut, the question is really about features. It sounds like there is redis
work we’d like to ship. Anything else nearly-done we should considering
waiting on?
From: Alexander Murmann <amurm...@vmware.com>
Date: Monday, November 30, 2020 at 11:57 AM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi all,
Thanks, Owen for reminding us all of this topic!
I wonder how we feel about the state of develop right now. If we cut
1.14 right now, it will make it easier to stabilize and ship it. However, I see
21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands
effort to address as much as possible on develop and then cut 1.14. If we shift
all attention to 1.14, develop will likely never get better. I'd love to get
closer to an always shippable develop branch. That should vastly reduce future
release pain and make everyday development better as well.
Thoughts?
________________________________
From: Jens Deppe <jde...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi Owen,
Thanks for starting this conversation and especially for volunteering
as Release Manager!
Since we're already a couple of quarters 'behind', in terms of
releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means
we'll have 9 months of changes to stabilize. How long might that take to
finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <onich...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has
been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will
volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based
release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14
branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <amurm...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off
cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut
the 1.14
release. The actual ship date for Geode 1.13 is important
information for
that conversation. Thus we cannot have that conversation before
then.
