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

31–40 of 64 posts

Re: Stop picking my Go version for me

#31

Post by Mawr »

> 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

Re: Stop picking my Go version for me

#32

Post by Mawr »

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.

Re: Stop picking my Go version for me

#35

Post by mzi »

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.

What hacks are you relying on that makes it impossible to upgrade to 1.25 or even 1.26?

Re: Stop picking my Go version for me

#36

Post by EdwardDiego »

Aurornis wrote: post #15
squiggleblaz wrote: post #7

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

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.

Re: Stop picking my Go version for me

#37

Post by bkdbkd »

dherls wrote: post #6

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

It forces a change, where none is called for. Compatibility works both ways. What doesn't matter to me the lib dev, may for matter for someone else. The world is built on portable, flexible code, and pinning to something unnecessarily, breaks that one small part of the world. It's adding an unnecessary requirement. Life is hard enough.

Re: Stop picking my Go version for me

#38

Post by mirashii »

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.

Using a release less than two months is hardly “so far behind”. The 1.24 series had considerable regressions that have taken a number of patch releases to fix, it stands to reason that the same would be true of newer releases. Given there's still miscompilations getting fixed as late as 1.25.8, and 1.25 brought in large changesets for the new experimental GC, sticking it out while 1.24 is still getting patches a mere handful of weeks ago is not unreasonable.

Re: Stop picking my Go version for me

#39

Post by masklinn »

bkdbkd wrote: post #33
charcircuit wrote: post #5

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

that is not a thing. it's not how compilers work.

Strictly speaking it does as miscompilations are a thing.

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.

Re: Stop picking my Go version for me

#40

Post by boomlinde »

Aurornis wrote: post #15
squiggleblaz wrote: post #7

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

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 think "minimum supported version" is a specific enough qualifier on its own. Whether or not it works on my favorite earlier version, actually supporting that version and making sure to maintain compatibility is more work for the maintainer.
Post reply on HN