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. > > >
