Re: [DISCUSS] Geode 1.14

[John Hutchison <hu...@vmware.com>]

Apologies if this detracts from the conversation of folks who have much more in depth knowledge of the codebase than I do- please feel free to ignore if this seems off base.

As a non-committing contributor  who works mostly on code outside of core Geode, it seems like  an always shippable develop would go a long way towards keeping the overall process feeling healthy.   It is, however,  frustrating to think of Redis work (with relies only on minor changes to geode core, along with other core in another module) being hung up while unrelated bugs are worked on. Not to complicate the conversation (and please feel free to ignore if this has been considered and thrown out before), but I wonder if it would be feasible (or desirable ) to try get to a place where we could ship parts of the code base separately, as “plugins, ” while continuing to work on the overall health of the core application?

From: Alexander Murmann <am...@vmware.com>
Date: Monday, November 30, 2020 at 2:57 PM
To: dev@geode.apache.org <de...@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 <jd...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <de...@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" <on...@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 <am...@apache.org>
    Date: Tuesday, July 28, 2020 at 4:34 PM
    To: dev@geode.apache.org <de...@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.