[ 
https://issues.apache.org/jira/browse/CASSGO-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17899198#comment-17899198
 ] 

Eric Evans commented on CASSGO-34:
----------------------------------

{{> [ ... ]}}

> At the same time, we can continue monitoring the ecosystem to understand when 
> moving to a higher go version becomes feasible.

One data point to consider is OS distributions.  Debian Bookworm (current 
Debian stable) ships 1.19, anyone building for deployment on Debian stable 
might be constrained to that.  Our deployments are to k8s using Bookworm-based 
images, that's how we ended up on 1.19.  I suspect that we'll be off of 1.19 
before Bookworm becomes EOL (via a backport), the same is probably true of 
others as well, so it's not necessarily the case that we would need to follow 
Debian's release cadence.
----
My suggestion would be to decouple the notion of "support", from that of 
"dependency".  The project could say: {_}"We only support 1.22 & 1.23"{_}, but 
if the code _will compile_ on 1.19 then that is the actual dependency, and that 
seems like the right version to put in {{{}go.mod{}}}.  Then it becomes a 
matter of deciding when it is apropos to actually change the dependency (again, 
independent of what is officially supported).  If there is a new language 
feature, the use of which would provide value that exceeds the desire to be 
backward compatible (but please be gentle :)), then bump the version to the 
minimum needed for that.  What is documented as "officially supported" is then 
there to ease the burden on the project (toolchain variability and 
reproducibility), and sets an expectation that what is in {{go.mod}} could be 
raised to the floor of those values when the need arises.

> Decide go version Bump for gocql  
> ----------------------------------
>
>                 Key: CASSGO-34
>                 URL: https://issues.apache.org/jira/browse/CASSGO-34
>             Project: Apache Cassandra Go driver
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Stanislav Bychkov
>            Priority: Normal
>             Fix For: 2.0.0
>
>
> The current {{go.mod}} file in gocql specifies go 1.13 as the minimum 
> version, which is outdated. Recent updates, including support for {*}Native 
> Protocol v5{*}, introduced dependencies such as {{{}atomic.Bool{}}}, which 
> require go 1.19 or higher to build successfully.
> GoCQL officially supports the *latest two Go releases* (currently *Go 1.22* 
> and {*}Go 1.23{*}) and uses these versions in its CI pipeline. However, we 
> need to determine whether to bump the {{go.mod}} version to:
>  # {*}Go 1.19{*}: The minimum version required to build with 
> {{{}atomic.Bool{}}}.
>  # {*}Go 1.22{*}: Align with GoCQL’s official policy of supporting the latest 
> two Go releases.
> This decision impacts users, as a higher {{go.mod}} version requires them to 
> upgrade their Go environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to