The wiki states:
"Geode cuts support branches for new minor releases on a time-based schedule
(Monday on or after Feb 1, May 1, Aug 1, Nov 1)."
I guess let's leave this inaccurate statement as-is for now until 1.13 has
shipped and we have a better sense of how releases will be initiated in the
future.
On 7/21/20, 11:57 AM, "Alexander Murmann" <ajmurm...@gmail.com> wrote:
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
