Owen, we cannot plan an updated timeline till we have shipped 1.13. If the goal is to avoid overlap between 1.13 and 1.14 and give folks a break, we need to know when 1.13 ships.
On Mon, Jul 20, 2020 at 4:57 PM Owen Nichols <onich...@vmware.com> wrote: > Current schedule for cutting support branches is: > Aug 3, 2020: cut support/1.14 > Nov 2, 2020: cut support/1.15 > Feb 1, 2021: cut support/1.16 > May 3, 2021: cut support/1.17 > > I have a hard time understanding how anyone can trust that our schedule is > "time-based" if we can change the dates at the last minute. But, I am > reminded that this is only a discussion thread at this point, not a > proposal yet. If it does become a proposal, I would just like to see > concrete dates proposed for the next few branch cuts. Any change to the > 1.14 branch cut date almost certainly must affect subsequent branch cut > dates. > > I agree that there needs to be some downtime in between release cycles. > Given that we came up with the quarterly cadence using an assumption of 1 > month to get a release out, but we've found that it actually takes 2-3 > months, maybe the quarterly cadence is just too aggressive? > > > On 7/20/20, 3:12 PM, "Alexander Murmann" <amurm...@apache.org> wrote: > > Hi Owen, > > I am not proposing to abandon our time-based releases. It's > unprecedented > for one of our releases to take this long. Even if we were to cut the > release now, it would likely not receive any attention till 1.13 is > out. So > I don't think there is any benefit in cutting the release now. In > addition > there are all the downsides, I discussed above that are unique to this > situation. > > > An aside: > > > [..] developers will hold off on high-risk changes and focus more on > > hardening as the cut date approaches. > > > To me that wasn't ever part of the reason for timed releases, but > predictability for users and for developers to know by when features > need > to be done to ship. If we feel a change is risky, let's write tests > till we > feel it's safe. > > > > On Mon, Jul 20, 2020 at 12:19 PM Owen Nichols <onich...@vmware.com> > wrote: > > > The Geode community adopted a time-based quarterly cadence two years > ago > > in the hope it would lead to higher stability and more predictable > > releases. The idea was that by knowing exactly when a branch cut is > > upcoming, developers will hold off on high-risk changes and focus > more on > > hardening as the cut date approaches. The flip side was that the > next > > release cut was never more than 3 months away, making it more > palatable to > > delay features to the next release for the greater good. > > > > I am concerned about reneging on this promise so close to a date that > > developers have already been planning around. Develop has seen 259 > commits > > since support/1.13 was cut, which is a full release worth. Some > feature > > work such as geode-redis is eagerly anticipating a prompt branch cut > and > > swift release thereafter. > > > > Are you proposing to abandon time-based release cadence entirely? > If not, > > can you provide more detail on the new schedule you are envisioning > (e.g. > > still 4x/yr, but shifted out by a month? Or move to 3x/yr, starting > by > > delaying 1.14 by a month?). > > > > I don't know if this is the forum to reflect on *why* it takes so > long to > > stabilize from develop and get to something releasable, but if we > accept > > that the release process routinely takes 2-3 months (not the 1 month > our > > quarterly cadence was predicated on), then taking this opportunity > to move > > to a 3x/year cadence might be the smart play. > > > > -Owen > > > > On 7/20/20, 9:55 AM, "Donal Evans" <doev...@vmware.com> wrote: > > > > +1 to postponing 1.14. > > > > Given the limited resources we have in terms of people who > shepherd > > the release process and ensure the quality of what we end up > releasing, it > > would put an unsustainable amount of strain on those who have > already been > > working extremely hard on getting 1.13 finished if we rolled right > into > > 1.14 without time to breathe and hopefully ramp up some more people > to take > > over parts of the release process. > > > > I'm also not in favour of abandoning 1.13 entirely, as there's > been a > > huge effort on the part of some community members to get it into a > good > > state to release, and dropping 1.13 now would effectively be seeing > all > > that work go to waste. It also wouldn't address the core issue that > those > > most heavily involved in the release process and in identifying and > > addressing potential release blockers are in danger of being > exhausted by > > the non-stop process of finding and fixing bugs in the release, > since 1.14 > > will have all of the same blockers that 1.13 currently has, plus an > > undetermined number of additional ones that we may not know about > yet. > > ________________________________ > > From: Jacob Barrett <jabarr...@vmware.com> > > Sent: Monday, July 20, 2020 9:38 AM > > To: dev@geode.apache.org <dev@geode.apache.org> > > Subject: Re: [Discuss] Cutting Geode 1.14 > > > > Alternatively, why not abandon 1.13 and try again with 1.14? > > > > > On Jul 20, 2020, at 9:21 AM, Alexander Murmann < > amurm...@apache.org> > > wrote: > > > > > > Hi everyone, > > > > > > TL;DR: Let's discuss 1.14 once 1.13 is out. > > > > > > If we stick to our cadence of cutting a release every 3 months > and > > shipping > > > it 1 month later, 1.14 is due to be cut two weeks from today. > > However, we > > > haven't shipped 1.13 yet and are still struggling with some > issues. > > > > > > I suggest that we postpone cutting the 1.14 release till we've > > actually > > > shipped 1.13. Once we've shipped 1.13, we should have another > > conversation > > > about timing of 1.14. I know the 1.13 release has been taxing > on many > > > people in our community and we might want to consider giving > > ourselves a > > > little bit of a gap between releases. > > > > > > > > -- Alexander J. Murmann (650) 283-1933
