[VOTE] Release dtest-api 0.0.6
Proposing the test build of in-jvm dtest API 0.0.6 for release. Repository: https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6 Candidate SHA: https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT tagged with 0.0.6 Artifact: https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/ Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C Changes since last release: * CASSANDRA-16148: Add IInstance#getReleaseVersionString The vote will be open for 24 hours. Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s. -- Alex
Re: [VOTE] Release dtest-api 0.0.6
+1 On 8 October 2020 at 10:20:22, Oleksandr Petrov (oleksandr.pet...@gmail.com) wrote: > Proposing the test build of in-jvm dtest API 0.0.6 for release. > > Repository: > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6 > > > Candidate SHA: > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT > > tagged with 0.0.6 > Artifact: > https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/ > > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > > Changes since last release: > > * CASSANDRA-16148: Add IInstance#getReleaseVersionString > > The vote will be open for 24 hours. Everyone who has tested the build is > invited to vote. Votes by PMC members are considered binding. A vote passes > if there are at least three binding +1s. > > -- Alex > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release dtest-api 0.0.6
+1 On Thu, Oct 8, 2020 at 3:20 AM Oleksandr Petrov wrote: > > Proposing the test build of in-jvm dtest API 0.0.6 for release. > > Repository: > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6 > > Candidate SHA: > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT > tagged with 0.0.6 > Artifact: > https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/ > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > > Changes since last release: > > * CASSANDRA-16148: Add IInstance#getReleaseVersionString > > The vote will be open for 24 hours. Everyone who has tested the build is > invited to vote. Votes by PMC members are considered binding. A vote passes > if there are at least three binding +1s. > > -- Alex - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release dtest-api 0.0.6
+1 On Thu, Oct 8, 2020 at 7:25 AM Brandon Williams wrote: > +1 > > On Thu, Oct 8, 2020 at 3:20 AM Oleksandr Petrov > wrote: > > > > Proposing the test build of in-jvm dtest API 0.0.6 for release. > > > > Repository: > > > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6 > > > > Candidate SHA: > > > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT > > tagged with 0.0.6 > > Artifact: > > > https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/ > > > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > > > > Changes since last release: > > > > * CASSANDRA-16148: Add IInstance#getReleaseVersionString > > > > The vote will be open for 24 hours. Everyone who has tested the build is > > invited to vote. Votes by PMC members are considered binding. A vote > passes > > if there are at least three binding +1s. > > > > -- Alex > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [VOTE] Release dtest-api 0.0.6
+1nb From: Jordan West Sent: Thursday, October 8, 2020 7:40 AM To: dev@cassandra.apache.org Subject: Re: [VOTE] Release dtest-api 0.0.6 +1 On Thu, Oct 8, 2020 at 7:25 AM Brandon Williams wrote: > +1 > > On Thu, Oct 8, 2020 at 3:20 AM Oleksandr Petrov > wrote: > > > > Proposing the test build of in-jvm dtest API 0.0.6 for release. > > > > Repository: > > > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6 > > > > Candidate SHA: > > > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT > > tagged with 0.0.6 > > Artifact: > > > https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/ > > > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > > > > Changes since last release: > > > > * CASSANDRA-16148: Add IInstance#getReleaseVersionString > > > > The vote will be open for 24 hours. Everyone who has tested the build is > > invited to vote. Votes by PMC members are considered binding. A vote > passes > > if there are at least three binding +1s. > > > > -- Alex > > - > 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: [VOTE] Release dtest-api 0.0.6
+1 (nb) On Thu, 8 Oct 2020 at 17:15, Scott Andreas wrote: > +1nb > > > From: Jordan West > Sent: Thursday, October 8, 2020 7:40 AM > To: dev@cassandra.apache.org > Subject: Re: [VOTE] Release dtest-api 0.0.6 > > +1 > > On Thu, Oct 8, 2020 at 7:25 AM Brandon Williams wrote: > > > +1 > > > > On Thu, Oct 8, 2020 at 3:20 AM Oleksandr Petrov > > wrote: > > > > > > Proposing the test build of in-jvm dtest API 0.0.6 for release. > > > > > > Repository: > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6 > > > > > > Candidate SHA: > > > > > > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT > > > tagged with 0.0.6 > > > Artifact: > > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/ > > > > > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > > > > > > Changes since last release: > > > > > > * CASSANDRA-16148: Add IInstance#getReleaseVersionString > > > > > > The vote will be open for 24 hours. Everyone who has tested the build > is > > > invited to vote. Votes by PMC members are considered binding. A vote > > passes > > > if there are at least three binding +1s. > > > > > > -- Alex > > > > - > > 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 > >
Request for shepherd on Repair validation
I spoke with Blake about https://issues.apache.org/jira/browse/CASSANDRA-15580 (new testing and validation for Repair) - and unfortunately he's not going to have the cycles to shepherd this validation in the immediate future. So here's the ask - is there anyone on the project that knows repair fairly well that has the cycles to step in and shepherd and guide this work? Thanks!
Supported upgrade path for 4.0
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?
Re: [DISCUSS] Updating the C* website design
Thanks to those who provided input on the new site layout. #3 was the winner with some additional comments, which we'll work to integrate. In tandem with the new website design, page content has been updated and/or created as new. Input would be greatly appreciated. The content doc, plus next steps for the site, can be found in the Jira ticket here: https://issues.apache.org/jira/browse/CASSANDRA-16115. Thanks! On Wed, Sep 30, 2020 at 12:42 PM Melissa Logan wrote: > Hi folks, > > As there were no dissenting votes, based on lazy consensus we have moved > forward with the project as outlined in CASSANDRA-16115: > https://issues.apache.org/jira/browse/CASSANDRA-16115 > > If you need a break from 4.0 debugging, would really love folks’ thoughts > on new design concepts. Elements/colors can be mixed-and-matched. See > designs here (you have to enter email to view, but it is not retained): > https://projects.invisionapp.com/freehand/document/7CLfsYoVb? > > Please share which you prefer and any comments here: > https://doodle.com/poll/4yc369baaug5dzw7 > > Any questions, just let me know. Thanks in advance. > > > On Fri, Aug 21, 2020 at 6:44 PM Rahul Singh > wrote: > >> Seems like even Antora uses another SSG called middleman for their >> “marketing” home page. >> >> https://gitlab.com/antora/antora.org >> >> If the convenience of having both content and docs all in one SSG for >> code maintenance is compatible with the aesthetic/ content / taxonomy >> strategy need for the site visitors, we’ll find out soon enough. >> >> >> >> >> rahul.xavier.si...@gmail.com >> >> http://cassandra.link >> The Apache Cassandra Knowledge Base. >> On Aug 21, 2020, 8:54 PM -0400, Rahul Singh , wrote: >> > Folks, >> > >> > I applaud the choice of Antora for documentation but I’m not sure it is >> the best choice for generating an appealing site. >> > >> > Antora’s self professed strength is in technical documentation. Do we >> want to stick to a “documentation” / utility look for the front facing site >> or for a blog? >> > >> > https://gitlab.com/antora/antora/-/issues/444 >> > >> > I don’t want to rehash any conclusion on choosing Antora for docs or >> whether asciidoc is the choice for writing documentation. >> > >> > Could we think about using something like Gatsby or similar for the >> front facing 5-10 pages + blog ? E. G. Skywalking uses vuepress. >> > >> > We can use asciidoc as the common format while using Antora for the >> docs and something else for the rest of the content ( >> https://www.gatsbyjs.com/plugins/gatsby-transformer-asciidoc/) >> > >> > Something like Gatsby can use both Markdown and Asciidoc and we can >> migrate from one to the other while still using the same tooling. >> > >> > Just some thoughts would love feedback! >> > >> > rahul.xavier.si...@gmail.com >> > >> > http://cassandra.link >> > The Apache Cassandra Knowledge Base. >> > On Jul 29, 2020, 1:28 PM -0400, M Brandon Williams , >> wrote: >> > > >> > > web >> >
Re: 4.0 GA scope: the opt-in approach (CALL TO ACTION)
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
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? >
Re: [VOTE] Release dtest-api 0.0.6
+1 On Thu, Oct 8, 2020 at 9:20 PM Oleksandr Petrov wrote: > Proposing the test build of in-jvm dtest API 0.0.6 for release. > > Repository: > > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6 > > Candidate SHA: > > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT > tagged with 0.0.6 > Artifact: > > https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/ > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > > Changes since last release: > > * CASSANDRA-16148: Add IInstance#getReleaseVersionString > > The vote will be open for 24 hours. Everyone who has tested the build is > invited to vote. Votes by PMC members are considered binding. A vote passes > if there are at least three binding +1s. > > -- Alex >
Re: Supported upgrade path for 4.0
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? > > >
Re: Supported upgrade path for 4.0
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
Re: [VOTE] Release dtest-api 0.0.6
With 7 +1 votes, and no -1s, the vote passes. On Fri, Oct 9, 2020 at 1:12 AM Nate McCall wrote: > +1 > > On Thu, Oct 8, 2020 at 9:20 PM Oleksandr Petrov < > oleksandr.pet...@gmail.com> > wrote: > > > Proposing the test build of in-jvm dtest API 0.0.6 for release. > > > > Repository: > > > > > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6 > > > > Candidate SHA: > > > > > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT > > tagged with 0.0.6 > > Artifact: > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/ > > > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > > > > Changes since last release: > > > > * CASSANDRA-16148: Add IInstance#getReleaseVersionString > > > > The vote will be open for 24 hours. Everyone who has tested the build is > > invited to vote. Votes by PMC members are considered binding. A vote > passes > > if there are at least three binding +1s. > > > > -- Alex > > > -- alex p
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 > >
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
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
