This sounds eminently sensible to me.
On 09/10/2020, 19:42, "Joshua McKenzie" <jmcken...@apache.org> wrote:
Fair point on uncertainties and delaying decisions until strictly required
so we have more data.
I want to nuance my earlier proposal and what we document (sorry for the
multiple messages; my time is fragmented enough these days that I only have
thin slices to engage w/stuff like this).
I think we should do a "From → To" model for both testing and supporting
upgrades and have a point of view as a project for each currently supported
version of C* in the "From" list. Specifically - we test and recommend the
following paths:
1. 2.1 → 3.0 → 4.0
2. 3.0 → 4.0 (subset of 1)
3. 3.11 → 4.0
There's no value whatsoever in hopping through an interim version if a
leapfrog is expected to be as tested and stable. The only other alternative
would be to recommend 2.1 → 3.11 → 4.0 (as Mick alluded to) but that just
exposes to more deltas from the tick-tock .X line for no added value as you
mentioned.
We could re-apply the "from-to" testing and support model in future
releases w/whatever is supported at that time. That way users will be able
to have a single source of truth on what the project recommends and vets
for going from wherever they are to the latest.
On Fri, Oct 09, 2020 at 12:05 PM, Benedict Elliott Smith <
bened...@apache.org> wrote:
> 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 < benedict@
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
