I just noticed CASSGO-34 [1] was created for this topic and there was some discussion there. I posted a comment on the JIRA ticket to see if we can focus the discussion on this thread.
Eric brought up in CASSGO-34 that we could keep the version on go.mod the actual required version to compile gocql and not necessarily the one that is officially supported because that would be beneficial for users that are not ready to upgrade Go on their critical production services right away. Personally I don't see an issue with using a Go version in go.mod that is lower than the versions the project officially supports but if we don't have any automated checks using that version then we might break compatibility with that version without being aware of it. Maybe this is ok since it's not officially supported? Adding another version to the test matrix kind of goes against what the project documents as officially supported Go versions, users might get confused when they look at the test matrix and see that there is a Go version there that is not officially supported. I'm +1 on keeping the Go version in go.mod the minimum version required to compile gocql and not necessarily keeping it in sync with the officially supported Go versions and I'm +0 on adding a "compile check" with that version in our CI to make sure we know right away when the version in go.mod needs to be updated. This doesn't mean we can't use features that require a higher version of Go, but we can be mindful and decide when it is worth doing that. [1] https://issues.apache.org/jira/browse/CASSGO-34 Jackson Fleming <jfleming.apa...@gmail.com> escreveu (terça, 19/11/2024 à(s) 22:11): > 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 >> >
