21–30 of 64 posts
How your go.mod should look: go 1.24.0 toolchain go1.25.7 "This module compiles with the language and runtime of go 1.24 and later, but I recommend you use at least go release 1.25.7" go get can manage this for you - https://go.dev/doc/toolchain#get
Same situation in Rust crates, AIUI.
and yet the Go maintainers did not include or build (in the future) a tool that determined the minimum version of Go that your application can be compiled in.
>My package really does depend on the latest patch release! > Even in the event that your packages code is only correct with a specific patch release, I still think its wrong to put that version in the go directive unless it cannot be compiled with any other version. I'm not a go user, but this strikes me as an over-reaction. If your code is only correct with a specific patch release, then it really is your business…
(Blog author)
Same situation in Rust crates, AIUI.
If you type 'cargo init', you will get 'edition = "2024"', but no 'rust-version'.
The situation is different because rust does not require a 'rust-version' in Cargo.toml, and in practice most crates do not have one, while in go it is required you specify a minimum version, there's no automation to set it to the true minimum, and most projects update it incorrectly in practice (because the go cli updates it incorrectly for you).
> Even in the event that your packages code is only correct with a specific patch release, I still think its not always right to put that version in the go directive unless it cannot be compiled with any other version.
This just makes me shiver. Imagine releasing a library with a version number slightly lower because of this post, it compiles, but there is a bug that brings down production...
Thanks but not thanks.
Weird that this needs to be said. I’m not familiar with the Go ecosystem, but there is usually a natural incentive for library developers to reach more people, which means you’d want to support the oldest feasible version. If you don’t do that then someone will develop a better library which does support an older version. Is that not happening here?
However, this behavior can be disabled (for example, when building for a Linux distribution).
>It is not the version you use to compile your project But it is the version which they support. Pushing it back to an older version may result in bad behavior even if it does compile.
I think only languages which are still in beta have that kind of back compatibility. If a language breaks compatibility every two years (roughly Debian’s release schedule), it’s a toy, not a tool.