Specify a go release minor version

[radsaq]

• PR Description
  Since they started releasing .0 versions with 1.21.0, the go version need to be a full release version specifier and not a go language version. They relented and added support for defaulting to a .0 release if none is specified in later 1.23.x releases, but for users with local 1.21 or 1.22 toolchains the lack of a full release specifier breaks them. And going forwards this is more technically correct anyway.

See golang/go#62278 (comment)

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

Makes sense to me. My only question is why you chose 1.24.1 and not 1.24.0; do we specifically require .1? Shouldn't we specify the minimum version that is required for building?

[radsaq]

Makes sense to me. My only question is why you chose 1.24.1 and not 1.24.0; do we specifically require .1? Shouldn't we specify the minimum version that is required for building?

This is an application and not a library so as far as I can tell there's no reason not to specify the latest version to make sure the app gets built with the latest bug/security fixes. It seems like for a library, specifying a lower version with the go directive but then a higher version with the 'toolchain' directive would be the right thing to do? But that only benefits people importing your code.

[stefanhaller]

But the go directive in go.mod does not specify the exact version that will be (needs to be) used to build. It specifies the minimum required version. If I set this to 1.24.0, I can build locally without problems even though I only have the 1.24.1 toolchain installed.

This doesn't say anything about what version will be used by packagers to build their distributions. I'd hope that they always use the latest available go version.

My understanding of this version is that we update it whenever we want to use language features that aren't supported by the older version. We shouldn't have to update it when a new go point release (or even major release) comes out that only has, say, performance improvements or security fixes.

Or at least that's my understanding, not sure if I got some of this wrong.

[radsaq]

Or at least that's my understanding, not sure if I got some of this wrong.

No, I'm pretty sure you're correct about all that. But also for anyone building the package (casual devs, people using go install to fetch directly from GH) with their GOTOOLCHAIN set to the default of auto, the app will compile using 1.24.0. So in that sense, it's not clear to me that keeping the version at .0 in the source actually benefits anyone. 🤔

(I believe the solution is for a user who cares to specify "go+auto" as their toolchain, but as someone who's new to this, it almost feels like that should be the default behavior if they're going to make downloading toolchains automatic. Maybe that's dumb? I dunno. 🤔)

[stefanhaller]

But also for anyone building the package (casual devs, people using go install to fetch directly from GH) with their GOTOOLCHAIN set to the default of auto, the app will compile using 1.24.0.

No, only for those users who are now using an older version. Users with a newer version will use their version to compile.

The go documentation is pretty clear about this:

The go line declares the minimum required Go version for using the module or workspace.
The toolchain line declares a suggested toolchain to use with the module or workspace.

So our go line should say 1.24.0. If we care about forcing users to use the latest security fixes, then we should add a toolchain directive, but then we also need to update it whenever a new go version is released. I don't think it makes sense for us to be doing that; every go application out there would have to.

To be honest I feel that this whole toolchain automatism is still a bit messed up (in several ways), but it's not our business to try to fix it.

[stefanhaller]

But also for anyone building the package (casual devs, people using go install to fetch directly from GH) with their GOTOOLCHAIN set to the default of auto, the app will compile using 1.24.0.

No, only for those users who are now using an older version. Users with a newer version will use their version to compile.

Oh, and for users who never bother to update their go installation, thinking that always downloading the latest toolchains is enough. With a GOTOOLCHAIN of "auto" they will compile with 1.24.0 even if they have newer toolchains installed. This feels really broken to me.

This actually just happened to me on my Windows box that I only use rarely; I forgot how I installed go there, and was too lazy to update it, thinking that downloading toolchains should be enough. With current lazygit master I can't even run commands like go version or even go --help:

$ go --help
go: downloading go1.24 (windows/amd64)
go: download go1.24 for windows/amd64: toolchain not available

(My local version is 1.22, so it does't have the fallback of appending .0 yet.)

What a mess. I now learned that I can fix this by doing go env -w GOTOOLCHAIN=go1.24.1+auto, and I just did, but it takes quite a bit of googling to figure this out.

But again, I don't think it's our job to find non-standard workarounds for all this. I would hope that package maintainers don't fall into this category of users that are too lazy to update their software.

[radsaq]

But also for anyone building the package (casual devs, people using go install to fetch directly from GH) with their GOTOOLCHAIN set to the default of auto, the app will compile using 1.24.0.

No, only for those users who are now using an older version. Users with a newer version will use their version to compile.

The go documentation is pretty clear about this:

The go line declares the minimum required Go version for using the module or workspace.
The toolchain line declares a suggested toolchain to use with the module or workspace.

So our go line should say 1.24.0. If we care about forcing users to use the latest security fixes, then we should add a toolchain directive, but then we also need to update it whenever a new go version is released. I don't think it makes sense for us to be doing that; every go application out there would have to.

To be honest I feel that this whole toolchain automatism is still a bit messed up (in several ways), but it's not our business to try to fix it.

It also says this:

To choose the toolchain, the go command first obtains a list of available toolchains. For the auto form, the go command downloads a list of available toolchains. For the path form, the go command scans the PATH for any executables named for valid toolchains and uses a list of all the toolchains it finds. Using that list of toolchains, the go command identifies up to three candidates:

the latest release candidate of an unreleased Go language version (1.N₃rcR₃),
the latest patch release of the most recently released Go language version (1.N₂.P₂), and
the latest patch release of the previous Go language version (1.N₁.P₁).

Except that testing with a 1.23.2 install (from ubuntu) and 1.24.0 (downloaded tarball) I found that an app specifying 1.23.x would use the latest 1.23.x patch release but lazygit specifying 1.24 or 1.24.0 would always use 1.24.0 instead of 1.24.1. So yes, it does feel a bit messed up and at this point I gave up and decided you were right.

(There was another recent fix around calculating the version to use, but I can't tell if that buggy behavior was what I was hitting. 🤦)

I can open a new PR later.

[radsaq]

What a mess. I now learned that I can fix this by doing go env -w GOTOOLCHAIN=go1.24.1+auto, and I just did, but it takes quite a bit of googling to figure this out.

But again, I don't think it's our job to find non-standard workarounds for all this. I would hope that package maintainers don't fall into this category of users that are too lazy to update their software.

Indeed, "what a mess" has been my thought repeatedly while researching this particular go language saga. 😓

[stefanhaller]

Why a new PR though? Just change this one.

[radsaq]

Why a new PR though? Just change this one.

I'm out of the habit of force pushing because of my git usage for work. 😅