And if it was a massive Golang bug, then maybe everyone needs to upgrade anyway.
(Blog author)
go 1.24.0
toolchain go1.25.7
go get can manage this for you - https://go.dev/doc/toolchain#get
Some environments might not even have the newer version available.
This may not get the project as many users, but not everyone who writes a 50 line project is trying to figure out which versions it supports and setting up full test matrices either.
What’re the actual, practical results of a package pushing you towards a higher go version that you wouldn’t otherwise have adopted right away? Why is this actually important to avoid beyond “don’t tell me what to do”?
Datadog won't be getting a renewal from us.
Yes, and then one week later the entire 1.24 branch entered EOL: https://endoflife.date/go
I can understand staying one version behind latest, to not be exposed to brand new bugs, which do happen, but staying two versions behind is pointless.
> 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.
I expect this should work equally well for Go.
Sure. But guess what, virtually nobody is going to find out what that "minimum version" is, and your blog post is not going to change that.
Just install the latest toolchain.
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.
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).
However, this behavior can be disabled (for example, when building for a Linux distribution).
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.
Furthermore the go version covers the stdlib so any bug there is resolved thus, and for obvious reasons those generally do not affect compilation.
I do not think this is a very compelling argument or likely to be an actual concern, but it is a thing.
No, it's the minimum version my project is tested with.
> This means when you put a version like 1.25.7, you are deciding for everyone that imports you, transitively or directly, that they MUST be on Go 1.25.7+ to compile their project.
That is fine. This isn't Python or Java, you have no reason to ever be more than one version behind the current release. Just upgrade, it's painless.
> The fact that it defaults to the latest version is just a bad default that people should change.
Funny that: "cmd/go: change go mod init default go directive back to 1.N" https://github.com/golang/go/issues/77653
> 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 to make that so. If someone downstream wants to use library_method_broadly_correct and not library_method_correct_only_with_latest, then downstream should patch your source to allow them to do something unsupported. That becomes their problem. If this is likely to be a significant problem that will affect many users, then this is a codesmell warning you that you've probably got two libraries which you're just jumbling together into one: the solution isn't to falsely gate a safe function behind a high dependency version, nor to falsely release a function to people who can't use it safely, but to publish each with its own requirements expressly stated.