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

Reply via email to