A JIRA dashboard for 1.14.0 might help. Do we currently have one? I am not sure whether there is some JIRA label introduced for the release of 1.14.0. A quick search of open JIRA that affects 1.14.0 returns 29 tickets.
Jianxia On Mon, Jan 4, 2021 at 3:43 PM Owen Nichols <onich...@vmware.com> wrote: > How to tell whether develop is stable? > > From: Jacob Barrett <jabarr...@vmware.com> > Date: Monday, January 4, 2021 at 8:59 AM > To: dev@geode.apache.org <dev@geode.apache.org> > Subject: Re: [DISCUSS] Geode 1.14 > Keep develop stable, cut when we want to release. If develop isn’t stable > we don’t cut until it is. There is no reason we can’t keep develop stable. > If develop is stable then there is no reason we can’t release when we want > to, whether that is a date or after a feature. > > -Jake > > > > On Jan 4, 2021, at 7:22 AM, Anilkumar Gingade <aging...@vmware.com> > wrote: > > > > 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. > > > > >
