Re: 4.0 GA scope: the opt-in approach (CALL TO ACTION)
At the end of the 7 day period, 26 issues remained with "4.0-triage" in their fixversion. All 4.0-triage/alphe/beta/rc fixversions have been removed from these remaining tickets and they are now flagged fixversion 4.0.x. Thanks everyone. On Thu, Oct 08, 2020 at 3:58 PM, Caleb Rackliffe wrote: > Opted one issue, CASSANDRA-15821, back into 4.0-rc, as it was meant to > complete the documentation for CASSANDRA-15909, which is already resolved. > > On Wed, Oct 7, 2020 at 2:27 PM David Capwell > wrote: > > Updated the link to exclude resolved; down to 27 remaining (was 32) > > https://issues.apache.org/jira/issues/ > ?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%204. > 0-triage%20and%20status%20!%3D%20Resolved > > On Oct 7, 2020, at 12:16 PM, Joshua McKenzie > > wrote: > > Thanks for taking action on that Scott. > > Just want to ping the list here as a reminder for everyone: 48 hours to > > go! > > Reminder: *anything you think is crucial for us to get in before 4.0 GA, > please remove the 4.0-triage FixVersion from the tickets by Friday*. > > Thanks. > > On Tue, Oct 06, 2020 at 11:57 PM, Scott Andreas > wrote: > > Thank you, Josh! Just took a pass and opted in 22 of the 55 tickets with > the triage keyword as of this evening, most of which are active this > > month > > or are for flaky/failing tests. > > – Scott > > > From: Joshua McKenzie Sent: Monday, October 5, > 2020 11:01 AM > To: dev@cassandra.apache.org > Subject: Re: 4.0 GA scope: the opt-in approach (CALL TO ACTION) > > Friendly reminder: please check the link in the previous email and > > remove > > the 4.0-triage version from any tickets you want to keep included in 4.0 > GA. > > Thanks. > > ~Josh > > On Fri, Oct 02, 2020 at 5:58 PM, Joshua McKenzie > wrote: > > As discussed on the contributor call, we collectively agreed to try > something new to determine scope for 4.0. Rather than going ticket by > ticket or "asking for forgiveness" and having people move things out > individually, we've flagged all tickets in the 4.0 scope that are still > open with the fixversion '4.0-triage' with the intent to "opt things > > in". > > Link: https://issues.apache.org/jira/issues/ > ?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%204.0-triage > > If there's a ticket you want to keep in the 4.0 release, please edit the > ticket and remove the '4.0-triage' fixversion. Let's target having this > done by End of Day Friday, October 9th (one week from now). > > If you don't have access to remove that fixver from a ticket, please > > reach > > out to me (jmckenzie), Jordan West, or Jon Meredith on the-asf slack in > #cassandra-dev or via DM and we'll help you out. > > At the end of day on Oct 9th, we'll go through and move every ticket > > that > > still has 4.0-triage into 4.0.x and have our scope for 4.0 GA. > > Sound good? > > ~Josh > > - 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 > >
Re: Supported upgrade path for 4.0
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" 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" > 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
Re: Supported upgrade path for 4.0
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" 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" > 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" 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
Re: Supported upgrade path for 4.0
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" > 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" 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
Re: Supported upgrade path for 4.0
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" 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" 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
Re: Supported upgrade path for 4.0
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" 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
Re: Supported upgrade path for 4.0
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. >
Re: Supported upgrade path for 4.0
> 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.
[GitHub] [cassandra-harry] ifesdjeen opened a new pull request #4: Update jackson dependency to 2.11.3 to force yaml to 1.26
ifesdjeen opened a new pull request #4: URL: https://github.com/apache/cassandra-harry/pull/4 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Supported upgrade path for 4.0
> > > Dropping support for upgrading from 3.0 to 3.11 > > Nobody is proposing dropping support, but my personal preference would be > to officially endorse encouraging users to go directly 3.0->4.0, which > would reduce the support burden for 3.0->3.11 and 3.11->4.0, as many users > will skip 3.11 entirely if we encourage them to do so. If you would prefer > to officially encourage 3.0->3.11->4.0, and I would prefer to officially > encourage 3.0->4.0, it seems reasonable to split the support burden for the > paths we want to officially endorse, and endorse both? How does one go about doing that when we must still support - upgrading from 2.2/3.0 to 3.11, and - upgrading from 3.11 to 4.0 And what do we mean by "officially supported upgrade paths"? Is it that we will accept fixes for it, or that we are committed to fixing it for you. If some folk are committing to helping users fix bugs with 3.0->4.0 upgrades, and others are committing to help users fix bugs with 3.11->4.0, then it sounds like we need to support both and that is a good thing.
Re: Supported upgrade path for 4.0
> Would it be necessary to go from 3.0 to 3.11 on the way to 4.0? I didn't > think that was required. That's what's being discussed, and Mick is proposing requiring it officially, to reduce support burden. > What has been fixed in 3.0 that hasn't been merged into 3.11 ? Nothing that I'm aware of, but how many bugs are unique to 3.11 that have not been discovered? > Dropping support for upgrading from 3.0 to 3.11 Nobody is proposing dropping support, but my personal preference would be to officially endorse encouraging users to go directly 3.0->4.0, which would reduce the support burden for 3.0->3.11 and 3.11->4.0, as many users will skip 3.11 entirely if we encourage them to do so. If you would prefer to officially encourage 3.0->3.11->4.0, and I would prefer to officially encourage 3.0->4.0, it seems reasonable to split the support burden for the paths we want to officially endorse, and endorse both? On 09/10/2020, 09:47, "Mick Semb Wever" wrote: I would personally prefer the community to officially recommend skipping > 3.11 to users that have not yet upgraded, as 3.0 and 4.0 have each had much > more attention given to them over the past several years. What has been fixed in 3.0 that hasn't been merged into 3.11 ? Dropping support for upgrading from 3.0 to 3.11 would be a weird deviation from the general practice of being able to upgrade from one major version to the next. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Supported upgrade path for 4.0
On 9 October 2020 at 10:23:02, Benedict Elliott Smith (bened...@apache.org) wrote: > I would personally prefer the community to officially recommend skipping 3.11 > to users > that have not yet upgraded, as 3.0 and 4.0 have each had much more attention > given to them > over the past several years. This would naturally lead to fewer issues filed > for 3.0->3.11 > and 3.11->4.0, as fewer users take this upgrade path. +1 Upgrades are painful even without hitting any issues so avoiding one upgrade should help users. /Marcus - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Supported upgrade path for 4.0
I would personally prefer the community to officially recommend skipping > 3.11 to users that have not yet upgraded, as 3.0 and 4.0 have each had much > more attention given to them over the past several years. What has been fixed in 3.0 that hasn't been merged into 3.11 ? Dropping support for upgrading from 3.0 to 3.11 would be a weird deviation from the general practice of being able to upgrade from one major version to the next.
Re: Supported upgrade path for 4.0
> > Perhaps if others want to explicitly encourage the 3.0->3.11->4.0 upgrade > path, we can split our resources accordingly? > Would it be necessary to go from 3.0 to 3.11 on the way to 4.0? I didn't think that was required.
Re: Supported upgrade path for 4.0
I would personally prefer the community to officially recommend skipping 3.11 to users that have not yet upgraded, as 3.0 and 4.0 have each had much more attention given to them over the past several years. This would naturally lead to fewer issues filed for 3.0->3.11 and 3.11->4.0, as fewer users take this upgrade path. Perhaps if others want to explicitly encourage the 3.0->3.11->4.0 upgrade path, we can split our resources accordingly? On 09/10/2020, 07:49, "Mick Semb Wever" wrote: Anyone have an opinion here or any formal prior art for us to build on? > Maybe this question should be more phrased as to which upgrade paths each individual has time in helping and fixing users out? If you are voting for official support for the 3.0 upgrade path then that should imply you are putting up your hand in helping provide that official support in the community. (Whatever officially supported is deemed to be) I am only for supporting upgrades from latest 3.11. It makes life a lot simpler for all of us, and helps focus our community time on CEPs and otherwise maintaining our supported branches. 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. regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Supported upgrade path for 4.0
Anyone have an opinion here or any formal prior art for us to build on? > Maybe this question should be more phrased as to which upgrade paths each individual has time in helping and fixing users out? If you are voting for official support for the 3.0 upgrade path then that should imply you are putting up your hand in helping provide that official support in the community. (Whatever officially supported is deemed to be) I am only for supporting upgrades from latest 3.11. It makes life a lot simpler for all of us, and helps focus our community time on CEPs and otherwise maintaining our supported branches. 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. regards, Mick
Re: Supported upgrade path for 4.0
If a user asked me today, I would tell them to test the following paths before attempting it in production: - 2.1.x ---> 2.1.latest ---> 3.11.latest ---> 4.0 - 2.2.x ---> 2.2.latest ---> 3.11.latest ---> 4.0 - 3.0.x ---> 3.0.latest ---> 4.0 - 3.x ---> 3.11.latest ---> 4.0 The upgrade paths from 2.1/2.2/3.0/3.x to 3.11 are well-established and known today although the procedure isn't documented on the Apache website. I'd be happy to get drafts in if there are no objections. Cheers!
Re: Supported upgrade path for 4.0
+1 to officially supporting 3.0 to 4.0, in addition to 3.11 to 4.0 upgrade paths On Thu, Oct 8, 2020 at 10:33 PM Jeff Jirsa wrote: > > I assumed it would be 3.0.x and 3.11.x > > I don’t know why we’d make 3.0-4.0 unofficial/unsupported - there’s no > technical reason I’ve seen > > > On Oct 8, 2020, at 9:21 PM, Anthony Grasso > wrote: > > > > Hi Josh, > > > > This is a really good question. I agree with David about making sure this > > is clearly documented. > > > > As far as the supported upgrade path goes, I think we should officially > > support only 3.11.x. I do understand the idea of giving users the > > flexibility to upgrade from 3.0.x. However, the simpler we can make the > > upgrade path the better. As you mentioned, historically there have been > > numerous upgrade bugs. To that, having one upgrade path will make > > maintenance and support easier. > > > > Kind regards, > > > >> On Fri, 9 Oct 2020 at 07:36, David Capwell wrote: > >> > >> Thanks for bringing this up, we really should document this and make > sure > >> the different upgrade paths are clearly documented and have proper > >> coverage. > >> > >> There was a conversation in slack a while back (started from > >> https://the-asf.slack.com/archives/CK23JSY2K/p1595906733435000) but not > >> formal or voted on, but the current upgrade targets were 3.0.x and > 3.11.x > >> (do others feel we should support other versions as well and if so > what?). > >> > >> For features, COMPACT STORAGE is getting a lot of attention right now, > so > >> would love to see clarity on how we go from a cluster with COMPACT > STORAGE > >> to 4.0 (is there min version support, what is the upgrade path, what > about > >> deleted rows, etc.). > >> > >> This is what I know about the current state of 4.0 upgrades at least. > >> > >> On Thu, Oct 8, 2020 at 11:48 AM Joshua McKenzie > >> wrote: > >> > >>> Related JIRA ticket: > >> https://issues.apache.org/jira/browse/CASSANDRA-15588 > >>> > >>> Description: > >>> > >>> "We've historically had numerous bugs concerning upgrading clusters > from > >>> one version to the other. Let's establish the supported upgrade path > and > >>> ensure that users can safely perform the upgrades in production." > >>> > >>> So the topic of discussion here: what is our supported upgrade path to > >> 4.0? > >>> Is this actually documented on our site or in our documentation? Spent > a > >>> few minutes poking around and didn't find anything. > >>> > >>> Anyone have an opinion here or any formal prior art for us to build on? > >>> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
