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.
