Hacker News Reader

Comment by dotwaffle | Hacker News Reader

Just watch as most libraries now update their go.mod to say 1.25, despite using no 1.25 features, meaning those who want to continue on 1.24 (which will still have patch releases for six months...) are forced to remain on older versions or jump through lots of hoops.

It's a "minimum" version, not a dependency lock!

View on HN

This is a common issue with Rust projects as well. At least with Rust you have the idea of "MSRV" (minimum supported rust version). I've never heard it discussed within Go's community.

There's no MSGV. Everyone pins the latest.

This also plagues dependencies. People pin to specific version (ie, 1.23) instead of the major version (at least 1.0 or at least 1.2, etc).

The "go x.yy" line in go.mod is supposed to be that MSGV, but `go mod init` will default it to the current version on creation. While you could have tooling like `cargo-msrv` to determine what that value would be optimal, the fact that only the latest two Go versions are supported means it's not particularly useful in most cases.

>Just watch as most libraries now update...

Haven't seen anything like this. Most packages actually have 1.13 in their go.mod

Rarely do I see at least 1.19

Now that I think about it more, when I've seen it happen before, it tends to be on projects that use dependabot / renovate. If any of those updates depend (directly or transitively) on a later version of Go, the go.mod would be bumped accordingly for them.

I have a vague feeling it was related to testcontainers or docker, and at the time that job's Go install was always at least 6 months behind. At least with recent Go, it'll switch to a later version that it downloads via the module proxy, that would have helped a lot back then :S

Never seen this happen. Most popular libraries support at least 2 previous versions

Reply on news.ycombinator.com