Version in `go.mod` could be lowered

[rgalanakis]

I need to use a slightly older Docker base image that only has Go 1.22.3 available. I had to pin back to River 0.9, because River 0.10 on uses 1.22.5. Ideally it'd use 1.22.0 unless there is some compelling reason, so people stuck on older 1.22 versions do not need to pin to older versions.

Hopefully I'm not off-base with this suggestion- given Go language versioning rules, it seems like I should be able to ignore the patch version, but as of Go 1.21 I don't think that's possible. So River version 0.10 and newer is only compatible with Go versions 1.22.5 and higher, released July 2 2024. But please let me know if I'm misunderstanding the issue I'm having, I don't follow Go packaging closely so may have missed something.

[bgentry]

Hmm, do you have any error messages to share about what you were running into? Our intention is to always support the 2 latest major Go versions, both of which we run in CI, so I’m curious why that works if you’re having issues due to the version specifier.

[rgalanakis]

Yeah, when I upgrade River to 0.11, I get this output:

go: downloading github.com/riverqueue/river v0.11.1
go: accepting indirect upgrade from github.com/riverqueue/river/riverdriver@v0.9.0 to v0.11.1
go: accepting indirect upgrade from github.com/riverqueue/river/riverdriver/riverpgxv5@v0.9.0 to v0.11.1
go: accepting indirect upgrade from github.com/riverqueue/river/rivertype@v0.9.0 to v0.11.1
go: accepting indirect upgrade from go@1.22.3 to 1.22.5

At which point my go.mod file has go 1.22.5

Then when I try to build inside the container, the error I get is:

go.mod requires go >= 1.22.5 (running go 1.22.3; GOTOOLCHAIN=local)

There's a bunch of stuff in https://go.dev/doc/toolchain

I figured out if I build with GOTOOLCHAIN=auto, the container will download 1.22.5, which should be ok. But this is not really ideal (ideally I'd want to use the version in the container, not download a new toolchain, which is why the go installation uses local).

I think the key line is this one:

Modules that are dependencies of other modules may need to set a minimum Go version requirement lower than the preferred toolchain to use when working in that module directly. In this case, the toolchain line in go.mod or go.work sets a preferred toolchain that takes precedence over the go line when the go command is deciding which toolchain to use.

From what I can parse, if you are targeting go 1.21 and 1.22, I think you should have go 1.21.0 and toolchain 1.22.5.

Our intention is to always support the 2 latest major Go versions, both of which we run in CI, so I’m curious why that works if you’re having issues due to the version specifier.

Interesting! Check out the 'Setup Go 1.21' output here: https://github.com/riverqueue/river/actions/runs/10296721804/job/28498552958 Also note, from the go env output in that run, GOTOOLCHAIN='auto'. It looks like your CI matrix is testing 1.22.5 repeatedly because it's being auto downloaded 😬

[bgentry]

lol yep, thank you for catching that and it’s why I was asking! Pretty important we get this dialed in 🙂

should be able to fix this up later today and get in the next release.

[brandur]

I think we got this figured out in #522, and will cut a release shortly.

@rgalanakis Keep the quality of life problem reports coming.