Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop picking my Go version for me

blog.howardjohn.info

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Stop picking my Go version for me

#51

Post by mid-kid »

jmalicki wrote: post #19
WhyNotHugo wrote: post #14

Earlier quoted context omitted.

Anyone with an older toolchain can’t build that library of anything that depends on it. Some environments might not even have the newer version available.

Anyone with an older toolchain is free to fork it on github, test with the older version, and CI to the project that tests with the older version, and submit a patch, too! 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.

Not a Go dev, but I typically set up a CI with the oldest toolchains I support (usually a debian release), and only bump those versions when I really need something from the latest versions. Locally I build with the most recent tools. This ensures good enough coverage for very little work, as I notice when I start using something that's newer and can bump the toolchain accordingly.

Re: Stop picking my Go version for me

#52

Post by bmitch3020 »

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/

Re: Stop picking my Go version for me

#53

Post by jmalicki »

mid-kid wrote: post #51
jmalicki wrote: post #19

Earlier quoted context omitted.

Anyone with an older toolchain is free to fork it on github, test with the older version, and CI to the project that tests with the older version, and submit a patch, too! 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.

Not a Go dev, but I typically set up a CI with the oldest toolchains I support (usually a debian release), and only bump those versions when I really need something from the latest versions. Locally I build with the most recent tools. This ensures good enough coverage for very little work, as I notice when I start using something that's newer and can bump the toolchain accordingly.

Sure, but if you start a new small project and throw it on GitHub, it's not totally insane to just put the version you tested. Just because someone put up their tiny library doesn't mean they've put in the effort to figure out which version they need.

Re: Stop picking my Go version for me

#54

Post by WhyNotHugo »

jmalicki wrote: post #19
WhyNotHugo wrote: post #14

Earlier quoted context omitted.

Anyone with an older toolchain can’t build that library of anything that depends on it. Some environments might not even have the newer version available.

Anyone with an older toolchain is free to fork it on github, test with the older version, and CI to the project that tests with the older version, and submit a patch, too! 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.

Are you sure you replied to the right comment? I'm not sure how this relates to the question being asked.

Re: Stop picking my Go version for me

#55

Post by wink »

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.

Re: Stop picking my Go version for me

#56

Post by jmalicki »

WhyNotHugo wrote: post #54
jmalicki wrote: post #19

Earlier quoted context omitted.

Anyone with an older toolchain is free to fork it on github, test with the older version, and CI to the project that tests with the older version, and submit a patch, too! 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.

Are you sure you replied to the right comment? I'm not sure how this relates to the question being asked.

I did.

If you have an older tool chain, it is on you to fix the library to build with the older tool chain, that's what open source is about!

Re: Stop picking my Go version for me

#57

Post by billsmithaustin »

EdwardDiego wrote: post #36
Aurornis wrote: post #15

Earlier quoted context omitted.

That part struck me as well. I agree with the premise that the field should represent the minimum supported version, but I don’t understand the argument that it shouldn’t be set to the minimum supported version that works. That’s the point of a minimum supported version field.

I'm struggling to think of a scenario where bumping the minimum Go version you support would be essential to fixing a bug though, because that would imply a massive Golang bug and AFAIK it's pretty stable. And if it was a massive Golang bug, then maybe everyone needs to upgrade anyway.

Or not a Golang bug at all but rather a new Golang feature that the developer chose to use rather than trying to be backward compatible with some older Golang versions.

Re: Stop picking my Go version for me

#58

Post by cweagans »

skybrian wrote: post #4
cweagans wrote: post #2

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

One potential reason is that Go does drop support for older OSes sometimes. For example, Go 1.22 is the newest version that works with older Mac OSes. https://go.dev/doc/go1.22#darwin

shrug maybe so. But then again, I can't say I'm too torn up about losing support for an EOL OS version.

Re: Stop picking my Go version for me

#60

Post by barelysapient »

Mawr wrote: post #32
barelysapient wrote: post #20

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.

So upgrade to 1.25? What reason could you possibly have to be so far behind? 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.

Heavily regulated industry with a lengthy change control process for this sort of thing.

Personally, I love all of the new Go stuff and I'm using the current version on my personal projects.

Post reply on HN