[VOTE] Release Apache Cassandra 4.0-alpha4
Proposing the test build of Cassandra 4.0-alpha4 for release. sha1: d00c004cc10986fc41c2070f9c5d0007e03a45c3 Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha4-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1202/org/apache/cassandra/cassandra-all/4.0-alpha4/ The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available here: https://dist.apache.org/repos/dist/dev/cassandra/4.0-alpha4/ The vote will be open for at least 96 hours (longer than normal, because of Easter holidays for many). 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. [1]: CHANGES.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha4-tentative [2]: NEWS.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha4-tentative regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
> > In a conversation with Mick we discussed keeping doc changes out as well. > Anyone object to eliding documentation changes from CHANGES.txt? > +1 It will just get too noisy otherwise.
Re: server side describe
+1 let's keep moving forward. Dinesh > On Apr 9, 2020, at 4:07 PM, Nate McCall wrote: > > Ok cool. It sounds like we are moving this towards a consensus? (at least > agreeing to disagree and moving forward). > > I very much the different inputs on this thread - thanks for a largely > healthy discussion folks. > > On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink wrote: > >> I'd be in favor of going with the newer DESCRIBE option. The original patch >> was mostly focused on just getting the CQL correct and used virtual tables >> because its what the initial feedback was to do. Robert added a lot of >> functionality on top of what was there which is what people were starting >> to ask for. I am in favor of just going off of his patch and moving >> forward. I initially heard post 4.0 so I know I haven't been focused on it >> but if theres desire to put it in 4.0 I am +1 on it and would like to see >> just going off of the Robert's latest patch. >> >> Chris >> >> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer >> >> wrote: >> >>> Thanks for your answer Alex. >>> >>> Some of the things we have explicitly (as a community) agreed to commit are still in >> progress, including several client protocol changes. And, to my understanding, if those are committed, it'll be what community has agreed upon. >>> >>> If the understanding of the community was that this patch was expected to >>> go in 4.0 then it makes sense to commit it there. >>> >>> If the discussion is about whether or not to include _some_ version of >>> the patch, I think including it makes sense, especially given the patch was there for a while and was not committed for non-technical reasons. If >>> we're trying to decide _which_ patch to commit, I'd personally focus on the original patch (to foster recognition), get it reviewed, and pick any changes that make it better from the follow-up one (to foster collaboration). >>> >>> I am fine going through both patches and figuring out a way to merge them >>> into one if Jon or somebody else is willing to review the output of that >>> merge >>> >>> >>> >>> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith < >>> bened...@apache.org> >>> wrote: >>> +1 all of this On 09/04/2020, 10:23, "Oleksandr Petrov" wrote: > My understanding is that a majority of people ended up in favor >> of a DESCRIBE approach. Robert made a patch for that approach >> (according to his comment it was discussed with Chris beforehand). This sounds like just a switch of API (in other words, you use the >>> same string generation, but return it via different means). From the (little) time I've spent looking at the patch, I remember that there wasn't >>> much common code between the two (sorry if I'm remembering it wrong). If the discussion is about whether or not to include _some_ version >>> of the patch, I think including it makes sense, especially given the patch >>> was there for a while and was not committed for non-technical reasons. >> If we're trying to decide _which_ patch to commit, I'd personally focus on >> the original patch (to foster recognition), get it reviewed, and pick >> any changes that make it better from the follow-up one (to foster collaboration). > Where do we draw the line? I would discuss changes on the case-by-case basis. Some of the >> things we have explicitly (as a community) agreed to commit are still in progress, including several client protocol changes. And, to my >> understanding, >>> if those are committed, it'll be what community has agreed upon. All further changes that weren't discussed yet - we can talk over. If it's something as trivial as server-side describe that doesn't risk stability but >> adds >>> a lot of value, it may make sense to include. But I woudln't attempt to >>> come up with a general rule for what we may or may not consider for now. On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer < benjamin.le...@datastax.com> wrote: > We have already discussed it for several days and I believe that >>> all the > points have been brought to the table. > > I took the time to read CASSANDRA-14825 this morning to >> understand the full > story. > All the discussion has been about using Virtual Tables versus >> using > DESCRIBE. > My understanding is that a majority of people ended up in favor >> of >>> a > DESCRIBE approach (skipping the details on purpose here). > Robert made a patch for that approach (according to his comment >> it was > discussed with Chris beforehand). > > The question here is should: we agree to put it in 4.0 even if >> the
Re: Keeping test-only changes out of CHANGES.txt
> > > updated docs in https://github.com/apache/cassandra/pull/528 > > > Thanks Eduard and Jon. Committed in https://github.com/apache/cassandra/commit/141ea26733e7e8fe022bc78f7fd68225013e8d14 - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
+1 as soon as we always have JIRA number in the commit description Sent from my iPhone > On 10 Apr 2020, at 14:41, Brandon Williams wrote: > > +1 for keeping doc changes out. Definitely no good reason for keeping them. > >> On Fri, Apr 10, 2020 at 1:39 PM Jon Haddad wrote: >> >> In a conversation with Mick we discussed keeping doc changes out as well. >> Anyone object to eliding documentation changes from CHANGES.txt? >> >> >> >> >> >> >> On Thu, Apr 9, 2020 at 1:07 AM Benjamin Lerer >> wrote: >> >>> +1 >>> >>> >>> >>> On Thu, Apr 9, 2020 at 9:28 AM Eduard Tudenhoefner < >>> eduard.tudenhoef...@datastax.com> wrote: >>> updated docs in https://github.com/apache/cassandra/pull/528 On Wed, Apr 8, 2020 at 11:39 PM Jordan West wrote: > +1 (nb) to the change and +1 (nb) to updating the docs to reflect this. > > Jordan > > On Wed, Apr 8, 2020 at 11:30 AM wrote: > >> +1 >> >>> El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: >>> >>> +1 >>> >>> Sent from my iPhone >>> On 8 Apr 2020, at 13:50, Joshua McKenzie > wrote: +1 >> On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe >>> >> wrote: > > +1 > >>> On 8 Apr 2020, at 15:08, Mick Semb Wever >>> wrote: >> >> Can we agree on keeping such test changes out of CHANGES.txt ? >> >> We already don't put entries into CHANGES.txt if it is not a change >> from any previous release. >> >> There was some discussion before¹ about this, and the problem >>> that >> being selective meant what ended up there being arbitrary. I >>> think >> this can be solved with an easy rule of thumb that if it only > touches >> *Test.java classes, or it is only about fixing a test, then it >> shouldn't be in CHANGES.txt. That means if the patch does touch any >> runtime code then you do still need to add an entry to CHANGES.txt. >> This avoids the whole "arbitrary" problem, and maintains > CHANGES.txt >> as user-facing formatted text to be searched through. >> >> If there's agreement I can commit to going through 4.0 changes >>> and >> removing those that never touched runtime code. >> >> regards, >> Mick >> >> ¹) > >> > >>> https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E >> >> > - >> 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 >> >> > -- Eduard Tudenhoefner e. eduard.tudenhoef...@datastax.com w. www.datastax.com >>> > > - > 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: Keeping test-only changes out of CHANGES.txt
+1 for keeping doc changes out. Definitely no good reason for keeping them. On Fri, Apr 10, 2020 at 1:39 PM Jon Haddad wrote: > > In a conversation with Mick we discussed keeping doc changes out as well. > Anyone object to eliding documentation changes from CHANGES.txt? > > > > > > > On Thu, Apr 9, 2020 at 1:07 AM Benjamin Lerer > wrote: > > > +1 > > > > > > > > On Thu, Apr 9, 2020 at 9:28 AM Eduard Tudenhoefner < > > eduard.tudenhoef...@datastax.com> wrote: > > > > > updated docs in https://github.com/apache/cassandra/pull/528 > > > > > > On Wed, Apr 8, 2020 at 11:39 PM Jordan West wrote: > > > > > > > +1 (nb) to the change and +1 (nb) to updating the docs to reflect this. > > > > > > > > Jordan > > > > > > > > On Wed, Apr 8, 2020 at 11:30 AM wrote: > > > > > > > > > +1 > > > > > > > > > > > El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: > > > > > > > > > > > > +1 > > > > > > > > > > > > Sent from my iPhone > > > > > > > > > > > >> On 8 Apr 2020, at 13:50, Joshua McKenzie > > > > wrote: > > > > > >> > > > > > >> +1 > > > > > >> > > > > > On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe > > > > > > > wrote: > > > > > >>> > > > > > >>> +1 > > > > > >>> > > > > > > On 8 Apr 2020, at 15:08, Mick Semb Wever > > wrote: > > > > > > > > > > Can we agree on keeping such test changes out of CHANGES.txt ? > > > > > > > > > > We already don't put entries into CHANGES.txt if it is not a > > > change > > > > > from any previous release. > > > > > > > > > > There was some discussion before¹ about this, and the problem > > that > > > > > being selective meant what ended up there being arbitrary. I > > think > > > > > this can be solved with an easy rule of thumb that if it only > > > > touches > > > > > *Test.java classes, or it is only about fixing a test, then it > > > > > shouldn't be in CHANGES.txt. That means if the patch does touch > > > any > > > > > runtime code then you do still need to add an entry to > > > CHANGES.txt. > > > > > This avoids the whole "arbitrary" problem, and maintains > > > > CHANGES.txt > > > > > as user-facing formatted text to be searched through. > > > > > > > > > > If there's agreement I can commit to going through 4.0 changes > > and > > > > > removing those that never touched runtime code. > > > > > > > > > > regards, > > > > > Mick > > > > > > > > > > ¹) > > > > > >>> > > > > > > > > > > > > > > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > > > > > > > > > > > > > - > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > -- > > > Eduard Tudenhoefner > > > e. eduard.tudenhoef...@datastax.com > > > w. www.datastax.com > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
In a conversation with Mick we discussed keeping doc changes out as well. Anyone object to eliding documentation changes from CHANGES.txt? On Thu, Apr 9, 2020 at 1:07 AM Benjamin Lerer wrote: > +1 > > > > On Thu, Apr 9, 2020 at 9:28 AM Eduard Tudenhoefner < > eduard.tudenhoef...@datastax.com> wrote: > > > updated docs in https://github.com/apache/cassandra/pull/528 > > > > On Wed, Apr 8, 2020 at 11:39 PM Jordan West wrote: > > > > > +1 (nb) to the change and +1 (nb) to updating the docs to reflect this. > > > > > > Jordan > > > > > > On Wed, Apr 8, 2020 at 11:30 AM wrote: > > > > > > > +1 > > > > > > > > > El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: > > > > > > > > > > +1 > > > > > > > > > > Sent from my iPhone > > > > > > > > > >> On 8 Apr 2020, at 13:50, Joshua McKenzie > > > wrote: > > > > >> > > > > >> +1 > > > > >> > > > > On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe > > > > > wrote: > > > > >>> > > > > >>> +1 > > > > >>> > > > > > On 8 Apr 2020, at 15:08, Mick Semb Wever > wrote: > > > > > > > > Can we agree on keeping such test changes out of CHANGES.txt ? > > > > > > > > We already don't put entries into CHANGES.txt if it is not a > > change > > > > from any previous release. > > > > > > > > There was some discussion before¹ about this, and the problem > that > > > > being selective meant what ended up there being arbitrary. I > think > > > > this can be solved with an easy rule of thumb that if it only > > > touches > > > > *Test.java classes, or it is only about fixing a test, then it > > > > shouldn't be in CHANGES.txt. That means if the patch does touch > > any > > > > runtime code then you do still need to add an entry to > > CHANGES.txt. > > > > This avoids the whole "arbitrary" problem, and maintains > > > CHANGES.txt > > > > as user-facing formatted text to be searched through. > > > > > > > > If there's agreement I can commit to going through 4.0 changes > and > > > > removing those that never touched runtime code. > > > > > > > > regards, > > > > Mick > > > > > > > > ¹) > > > > >>> > > > > > > > > > > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > > > > > > > > > > - > > > > 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 > > > > > > > > > > > > > > > > > -- > > Eduard Tudenhoefner > > e. eduard.tudenhoef...@datastax.com > > w. www.datastax.com > > >
Re: Drivers support for Cassandra 4.0
Love it - thanks for the update Alex! I agree with Jordan this will be a big help with 4.0 adoption. Jon On Fri, Apr 10, 2020 at 10:40 AM Jordan West wrote: > On Thu, Apr 9, 2020 at 7:30 AM Alexandre Dutra < > alexandre.du...@datastax.com> > wrote: > > > * Java drivers 3.9.0 and 4.6.0 will be released in the next few weeks. > > They will include > > support for missing features (transient replication and > > now-in-seconds), effectively > > providing complete support for protocol v5 in its current state. To > > make it as easy as > > possible for users to adopt C* 4.0, we decided to release both major > > branches of the Java > > driver, including 3.x, even if this branch is now in maintenance mode. > > > > This is great to hear and I think will be a big benefit to 4.0 adoption. > > Thanks for the update! > Jordan >
Re: Drivers support for Cassandra 4.0
On Thu, Apr 9, 2020 at 7:30 AM Alexandre Dutra wrote: > * Java drivers 3.9.0 and 4.6.0 will be released in the next few weeks. > They will include > support for missing features (transient replication and > now-in-seconds), effectively > providing complete support for protocol v5 in its current state. To > make it as easy as > possible for users to adopt C* 4.0, we decided to release both major > branches of the Java > driver, including 3.x, even if this branch is now in maintenance mode. This is great to hear and I think will be a big benefit to 4.0 adoption. Thanks for the update! Jordan
