You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Alexander Murmann <am...@apache.org> on 2020/07/20 16:21:57 UTC
[Discuss] Cutting Geode 1.14
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.
Re: [Discuss] Cutting Geode 1.14
Posted by Mark Hanson <ha...@vmware.com>.
Playing devil's advocate here, but I think the reason we would not like to move to 1.14 would be that we have a ton testing already in to quantify issues on 1.13 and 1.14 would be (a bit) of an unknown quantity. Further, the core issues that we are waiting on for 1.13 are presumable 1.14 issues as well.
Thanks,
Mark
On 7/20/20, 9:39 AM, "Jacob Barrett" <ja...@vmware.com> wrote:
Alternatively, why not abandon 1.13 and try again with 1.14?
> On Jul 20, 2020, at 9:21 AM, Alexander Murmann <am...@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.
Re: [Discuss] Cutting Geode 1.14
Posted by Alexander Murmann <aj...@gmail.com>.
I think re-cutting 1.13 from current develop is interesting, but I think I
agree with Donal that the amount of additional risk might not be worth it.
Geode 1.13 already has some cool new features like SNI support that I
believe some users have been waiting for and I'd hate to not get that out
for another 2 months.
It also would be nice to get something out and get a little bit of a
breather, rather than running the risk of another 2 months of full-steam.
On Mon, Jul 20, 2020 at 9:55 AM Donal Evans <do...@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 <ja...@vmware.com>
> Sent: Monday, July 20, 2020 9:38 AM
> To: dev@geode.apache.org <de...@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 <am...@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
Re: [Discuss] Cutting Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
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" <aj...@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 <on...@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" <am...@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 <on...@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" <do...@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 <ja...@vmware.com>
> > Sent: Monday, July 20, 2020 9:38 AM
> > To: dev@geode.apache.org <de...@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 <
> amurmann@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
Re: [Discuss] Cutting Geode 1.14
Posted by Alexander Murmann <aj...@gmail.com>.
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 <on...@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" <am...@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 <on...@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" <do...@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 <ja...@vmware.com>
> > Sent: Monday, July 20, 2020 9:38 AM
> > To: dev@geode.apache.org <de...@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 <
> amurmann@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
Re: [Discuss] Cutting Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
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" <am...@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 <on...@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" <do...@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 <ja...@vmware.com>
> Sent: Monday, July 20, 2020 9:38 AM
> To: dev@geode.apache.org <de...@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 <am...@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.
>
>
>
Re: [Discuss] Cutting Geode 1.14
Posted by Alexander Murmann <am...@apache.org>.
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 <on...@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" <do...@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 <ja...@vmware.com>
> Sent: Monday, July 20, 2020 9:38 AM
> To: dev@geode.apache.org <de...@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 <am...@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.
>
>
>
Re: [Discuss] Cutting Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
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" <do...@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 <ja...@vmware.com>
Sent: Monday, July 20, 2020 9:38 AM
To: dev@geode.apache.org <de...@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 <am...@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.
Re: [Discuss] Cutting Geode 1.14
Posted by Donal Evans <do...@vmware.com>.
+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 <ja...@vmware.com>
Sent: Monday, July 20, 2020 9:38 AM
To: dev@geode.apache.org <de...@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 <am...@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.
Re: [Discuss] Cutting Geode 1.14
Posted by Jacob Barrett <ja...@vmware.com>.
Alternatively, why not abandon 1.13 and try again with 1.14?
> On Jul 20, 2020, at 9:21 AM, Alexander Murmann <am...@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.