>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 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.

How your go.mod should look:

    go 1.24.0

    toolchain go1.25.7

go get can manage this for you - https://go.dev/doc/toolchain#get

In other ecosystems, I could see how this could be a problem, but I don’t think I’ve ever had a problem with a Go upgrade.

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”?

The author fails to mention any of the negative effects they experience due to this go version selection. They say that the effect is "viral" but don't give any concrete examples of why it's a bad thing to keep your toolchain up to date

I used to see supporting multiple versions of Python as an expensive chore... and then I learned how to use the GitHub Actions matrix feature and supporting multiple versions is suddenly easy - my test suites are comprehensive enough that if they pass I'm confident it will work on that version.

I expect this should work equally well for Go.

Or, I have only tested my library on this version, and nothing lower.

> 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.

But how do you know which minimum version you need?

Install the latest version of Go and once you are finished with the library, downgrade the version of Go by one until you get a compilation error?

This is also a ticking bomb for the Go ecosystem due to how the 1.0 guarantee was updated. Originally, the guarantee was they would never make a language change that altered behavior in a breaking way, ever. But when the change to variables in the for loop was introduced, they changed the compiler to interpret the code differently based on the go.mod version of that package. So far, we've been lucky to only have changes everyone seems to have liked. But that could change in the future since the Go maintainers have made it clear there won't be a v2 of Go, they'll just make any breaking changes dependent on the go.mod version.

This is made even worse by the golang.org/x packages updating their minimum Go version without any other changes to the code that require that bump. It ripples through all projects that have any dependencies on those packages, and it forces everyone to choose between security updates and backward compatibility.

I've ranted about this before in my blog [1].

[1]: https://bmitch.net/blog/2025-06-07-go-broke-v1/

This just got me. Datadog decided that they only support the current and last major versions of Go. So, 1.26 and 1.25. But in my cause we're still on 1.24.13 which was released by the Go team less than two months ago.

Datadog won't be getting a renewal from us.

My solution for this is just use the current latest, or latest-1. There’s no reason not to. If your code is somehow stuck with an old version of Go, it should be considered a high priority bug, this is not normal.

I've seen this misconception so many times in open source projects - commits just bumping the version in go.mod to 'get the latest performance and security improvements.' Like no, that's not how it works, you just made your code compile with fewer compiler versions for no reason.

I think the directive could have been named better though, maybe something like min_version.

The transitive dependency case is what makes this painful in practice. You’re not even choosing that library it’s three levels deep in your dependency tree, and suddenly CI fails because some maintainer ran `go get go@latest` on a Saturday.

Unless I am mistaken or had some other fluke it will also just happily download the old version and build with that, even if there was a vulnerability, which has mostly led me to always bumping to the latest release when I touch it.

Someone n another thread mentioned the `toolchain` command, maybe I should look into this again.

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?

> The version is the minimum version your project can be compiled with.

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

> The version is the minimum version your project can be compiled with.

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.

The issue I'm having with this is, that I'm using the newest version to test my library

Does go support automatic testing of all version from X..Y?

Otherwise I don't see it being usable to define another version than the one I'm testing with in my go.mod

>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 always stay up with the latest go releases and if I am touching one of my packages that are set to lower in go.mod, I update it. It is an easy maintenance task to make sure I am keeping up with the latest standard library and tooling changes and improvements.

Could there be a user dialog prompt about the suggested version and some control flow that allows people to manually override during installation as a happy medium between these approaches

> Its not your responsibility to ensure transitive importers of your library are on the latest version of Go. Don't make that decision for them.

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.

Same situation in Rust crates, AIUI.

Couldn't agree more.