; If we are going to put 1.19 in the go.mod file - we should consider adding
> some tests against it, to ensure compatibility doesn't get broken by
> mistake?
>
> On Fri, Nov 8, 2024 at 3:13 AM João Reis wrote:
>
>> The Go version that is specified in "go.mod" is 1.1
ircular dependency, we really shouldn't ever be in the
> situation where we have that happening, at best it'll look odd to people
> paying attention, but it'll probably lead to headaches later on if we leave
> it. Probably best to do that before cutting a 2.0.0 release?
>
>
The Go version that is specified in "go.mod" is 1.13 but this is out of
date, 1.17 is required to build GoCQL at the moment. Bumping the version on
this file to 1.17 needs to be done regardless but should we bump this
version to the minimum Go version that GoCQL officially supports or the one
that
The goal of CASSGO-21 [1] is to move HostPoolHostPolicy out of the main
package so that users don't have to download the
github.com/hailocab/go-hostpool dependency if they are not using this
specific policy.
The question is whether we want to move this policy to a separate module or
if it is enough
urely help. Low hanging fruit should also not be a problem for
> me to review.
>
> Are we looking to review/triaging all existing PRs?
>
> Thanks,
>
> Carlos
> --
> *From:* João Reis
> *Sent:* 11 October 2024 16:03
> *To:* dev@cassandra.ap
name the module in 2.0.0 and
> there would be v5 and vector support as well. It would motivate us to get
> v5 and vector out while using that opportunity to rename it to 2.0.0.
>
> On Thu, Oct 10, 2024 at 11:42 AM João Reis wrote:
>
>> Hi,
>>
>> Following the GoCQL dona
es yet)
2) Release 2.0.0 with the module name change, some (if not all) of the
"semver-major" tagged issues and other contributions
Let me know your thoughts,
João Reis
[1] https://github.com/apache/cassandra-gocql-driver/issues/1776
[2] https://issues.apache.org/jira/browse/CASSANDRA-1999
Reducing the scope of CEP-32 to OpenTelemetry Tracing is a good idea (or
creating a new one). We recently added OpenTelemetry Tracing support to the
C# driver [1] and we also decided to not include Metrics and Logs in this
initiative because the driver already provides a way to collect metrics and
+1 (nb)
Bret McGuire escreveu (quinta, 26/09/2024 à(s)
21:46):
>Greetings all!
>
>I’m proposing the Cassandra Gocql Driver 1.7.0 for release.
>
> sha1: 953e0df999cabb3f5eef714df9921c00e9f632c2
> git: https://github.com/apache/cassandra-gocql-driver/tree/v1.7.0-rc1
>
>The Source relea
> I agree, let's remove it. We've had a history of "windows champions"
> (oh, hi Josh) and I don't see a clear one here, nor do I think that's
> a good methodology to promote in the long term (and history shows
> this, too.) Clearly, 90+% of C* actual usage is on a unix-like
> system, so this is
Personally I still use CCM on windows pretty often and the C# driver even
has an appveyor job that runs tests with CCM on windows (the drivers smoke
tests job does this as well). Setting up clusters with multiple nodes is
not that easy with Docker and WSL 2 because the nodes run inside a VM.
In re
+1 (nb)
The drivers smoke test suite looks good:
https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004
Mick Semb Wever escreveu no dia sábado, 18/07/2020 à(s)
00:27:
> Proposing the test build of Cassandra 4.0-beta1 for release.
>
> sha1: 972da6fcffa87b3a1684362
+1 (non-binding)
I've run the drivers smoke test suite and build jobs look good (there's 1
test failure that is not related to the server build):
https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34108936
Mick Semb Wever escreveu no dia quarta, 15/07/2020 à(s)
00:06:
+1 (non-binding)
I added a job to the drivers smoke test suite that runs the C# driver tests on
Windows and the test run looks good:
https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/32165091/job/07ms8wux19ojnr21
De: Jordan West
Enviad
14 matches
Mail list logo
