There is a sizeable cohort of us who I expect to be primarily focused on
3.0->4.0, so if you have a cohort focusing primarily on 3.11->4.0 I think we'll
be in good shape.
> For all subsequent major releases, we test and officially support only 1
> major back
I think we should wait to see what happens before committing ourselves to
something like this - things like release cadence etc will matter a lot. That
is *definitely* not to say that I disagree with you, just that I think more
project future-context is needed to make a decision like this. I expect we'll
have lots more fun (hopefully positive) conversations around topics like this
in the coming year, as I have no doubt we all want to evolve our approach to
releases, and there's no knowing what we'll end up deciding (we have done some
crazy things in the past __ ).
On 09/10/2020, 16:46, "Joshua McKenzie" <jmcken...@apache.org> wrote:
I think it's a clean and simple heuristic for the project to say "you can
safely upgrade to adjacent major versions".
The difficulty we face with 3.0 is that it has made many contributors very
wary of pre 4.0 code and with good reason. Your point about conservative
users upgrading later in a cycle resonates Benedict, and reflects on the
confidence we should or should not have in 3.11. I think it's also
important to realize that many cluster upgrades can take months, so it's
not a transient exposure to unknowns in a release.
I propose the following compromise:
1. For 4.0 GA, we consider the following upgrade paths "tested and
supported": 2.1 → 3.0 → 3.11 → 4.0, and 2.1 → 3.0 → 4.0
2. For all subsequent major releases, we test and officially support
only 1 major back
3. Any contributor can optionally meet whatever bar we set for "tested
and supported" to allow leapfrogging versions, but we won't constrain GA
on
that.
We have to pay down our debt right now, but if we have to continue to do
this in the future we're not learning from our mistakes.
Speaking for DataStax, we don't have enough resources to work through the
new testing work on 40_quality_test, the defects that David is surfacing
like crazy (well done!), and validating 2 major upgrade paths. If you and a
set of contributors could take on the 3.0 → 4.0 path Benedict, that'd be a
great help. I also assume we could all collaborate on the tooling / infra /
approaches we use for this validation so it wouldn't be a complete re-work.
On Fri, Oct 09, 2020 at 11:02 AM, Benedict Elliott Smith <
bened...@apache.org> wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
