Re: [DISCUSS] Go version in go.mod (GoCQL)

[Jackson Fleming]

I personally think we should strive to align the go version in go.mod to
what we test against and officially support, it clearly describes what the
project is built and tested against to other developers/users, but happy to
be told that's overkill and 1.19 is fine. If there is a time to push to
newer go versions though, it's during a major release of the driver.

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.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 is actually required to build? For context, GoCQL officially supports
> the latest 2 Go releases (currently 1.22 and 1.23) and these versions are
> what we use in CI.
>
> This topic was brought up while reviewing the PR [1] for CASSGO-1 (v5
> support) [2] because a reference to "atomic.Bool" was added which requires
> Go 1.19.
>
> Personally I don't think we have to bump the version on go.mod to a
> version that we test against in CI but bumping it to 1.19 seems reasonable
> to me.
>
> Bumping the version on go.mod to a version that we use in CI would allow
> us to use new Go features sooner but it would also require every user to
> upgrade the Go version on their application.
>
> [1] https://github.com/apache/cassandra-gocql-driver/pull/1822
> [2] https://issues.apache.org/jira/browse/CASSGO-1
>

Re: [DISCUSS] GoCQL sub modules vs packages

[Jackson Fleming]

I concur with the approach of having a single module for the driver, I
don't think this project is complicated enough yet to require
separate modules, the project is new to the Apache foundation and keeping
things simple will make it easier for people to learn and contribute.

I also agree that we need to look at moving lz4 from its own module into
the gocql module as a package. I think that it makes sense to do this to
remove the circular 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?

On Fri, Nov 8, 2024 at 2:55 AM João Reis  wrote:

> 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 to move it to a separate package on the same module.
> There is currently an open PR for this issue that uses the separate package
> approach [2].
>
> The way we choose to resolve CASSGO-21 should dictate what we do in the
> future for similar "extension" like code. For example, the PR [4] for
> CASSGO-9 [3] adds 2 "extensions" that provide out of the box functionality
> to use the logging libraries "zap" and "zerolog" with gocql and these are
> implemented in their own independent modules that are located in an
> "extensions" folder of gocql's repository.
>
> Lz4 support is also implemented as an independent module at the moment and
> as part of CASSGO-1 (protocol v5 support) we need to run the integration
> test suite with lz4 compression since snappy is not supported in protocol
> v5 but this creates a circular dependency between "gocql/go.mod" and
> "gocql/lz4/go.mod". For context, CI only uses snappy compression on
> integration tests at the moment. The circular dependency might be ok since
> its usage in the "gocql" package is limited to "_test.go" files, but it
> doesn't look great.
>
> In summary, I think we should either move HostPoolHostPolicy to a new
> module or we should consider making "gocql/lz4" a package instead of a
> module and changing CASSGO-9's patch so that zap and zerolog support is
> also implemented in separate packages instead of modules.
>
> In my opinion we should use packages within the main "gocql" module for
> this instead of separate modules (at the very least for
> "HostPoolHostPolicy" and "lz4"). Separate modules could make sense when we
> want to independently version and release a particular "extension" but in
> my opinion I don't think we have that requirement for the specific use
> cases that I've mentioned so far.
>
> [1] https://issues.apache.org/jira/browse/CASSGO-21
> [2] https://github.com/apache/cassandra-gocql-driver/pull/1770
> [3] https://issues.apache.org/jira/browse/CASSGO-9
> [4] https://github.com/apache/cassandra-gocql-driver/pull/1755
> [5] https://issues.apache.org/jira/browse/CASSGO-1
>

RE: [DISCUSS] GoCQL sub modules vs packages

[Stanislav Bychkov]

I'm in favor of the packages approach as discussed. Reference to my earlier
comment here: GitHub Issue #1770

 .

RE: [DISCUSS] Go version in go.mod (GoCQL)

[Stanislav Bychkov]

On the topic of updating the go version for gocql.
As the recent maintainer, Martin Sucha, mentioned:

> In our README, we state:
>> In general, the Cassandra community will focus on supporting the current
and previous versions of Go.

> So it should be safe to bump to 1.22.


However, it should be considered that some (legacy) projects may want to
use new gocql features without upgrading their go version. Users on go
1.19–1.21 would need to upgrade, which may not be feasible for all.

It would be beneficial to research the versions used by other projects that
depend on gocql. This way, we can make a better decision, aiming to adopt
the latest features while balancing compatibility.

Taking the current state, bumping to go 1.19 seems the most balanced for
now:
- It meets our current technical requirement (atomic.Bool).
- It minimizes disruptions by supporting a broader range of users who are
still migrating to newer versions of go.
For now, it might make sense to keep in mind to upgrade the minimum
requirement at go 1.19 and only revisit this when we have strong arguments
to upgrade further, perhaps around the gocql 2.0 release.

There's also a good discussion on this topic in slack:
https://the-asf.slack.com/archives/C05LPRVNZV1/p1725459369234389