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 <joaor...@apache.org> 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 >
