Since email is very unclear and context gets lost, I'm personally OK with
officially supporting all of these upgrade paths, but the spectre was raised
that this might lead to lost labour due to an increased support burden. My view
is that 3.0->4.0 is probably a safer upgrade path for users and as a result a
lower support cost to the project, so I would be happy to deprecate 3.0->3.11
if this helps alleviate the concerns of others that this would be costly to the
project. Alternatively, if we want to support both but some feel 3.0->4.0 is
burdensome, I would be happy to focus on 3.0->4.0 while they focus on the paths
I would be happy to deprecate.
On 09/10/2020, 15:49, "Benedict Elliott Smith" <bened...@apache.org> wrote:
Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
I think there's anyway a big difference between supported and encouraged.
I think we should encourage 2.1->3.0->4.0, while maintaining support for
2.2->3.0 and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal way
given the userbase that is already on 3.11.
> we can expect it to be *stable enough to upgrade through*
I don't know that this is true at all. Most bugs are not found by the
general userbase, and the most conservative (hence most likely to spot problems
on upgrade) are generally very late to the party. 2.1(2.2)->3.0 is still
discovering bugs today, many years after this metric was passed for 3.0 -
largely as the more sophisticated users upgrade.
On 09/10/2020, 15:40, "Marcus Eriksson" <marc...@apache.org> wrote:
My suggestion for "supported" upgrade paths would be;
2.1 (2.2) -> 3.0 -> 4.0
2.1 (2.2) -> 3.11 -> 4.0
and drop support for 3.0 -> 3.11 when we release 4.0
/Marcus
On 9 October 2020 at 16:12:12, Joshua McKenzie (jmcken...@apache.org)
wrote:
> Some data that I believe is relevant here.
>
> Numerically it's safe to assume there's over 10,000 ASF C* clusters
out in
> the world (5,500 in China alone). In surveys (both informal polling
and
> primary research), at least 1/3rd of folks are running the 3.X latest
if I
> recall correctly.
>
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so
we can
> expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping
majors
> (3.0->4.0). Depending on how we define "done" and "supported" for
upgrade
> testing, this will represent a significant development burden.
>
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as
far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as
an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>
>
>
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>
> > At The Last Pickle we have always recommended avoiding 3.0,
including
> > upgrading from 2.2 directly to 3.11.
> > We (now DataStax) will continue to recommend that folk upgrade to
the
> > latest 3.11 before upgrading to 4.0.
> >
> > To clarify that^, if it wasn't obvious, I wasn't making a statement
about
> > DataStax at at large, but about those of us at TLP and now the team
> > providing the consulting for Apache Cassandra from DataStax.
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
