What do you think? 🤔

I think this topic is slowly killing me. 😅

Thank you for your comprehensive write up. I think what we need to definitely iron out here is what the valid versions are for the go directive.

My position (loosely held because I find the Go docs for this hard to read) is that 1.22 is valid, where you believe we need 1.22.x.

Let's start with this statement:

A go directive indicates that a module was written assuming the semantics of a given version of Go. The version must be a valid Go version, such as 1.9, 1.14, or 1.21rc1.

Jumping over to the go version doc:

The syntax ‘1.N’ is called a “language version”. It denotes the overall family of Go releases implementing that version of the Go language and standard library.

And:

Any two Go versions can be compared to decide whether one is less than, greater than, or equal to the other
...
For example, 1.21 < 1.21rc1 < 1.21rc2 < 1.21.0 < 1.21.1 < 1.21.2.

From this paragraph, 1.21 is being listed as a comparable Go version. This leads me to believe that all language versions are go versions but only some go versions are language versions.

As you called out:

While go should be "as low as possible"

Since I'm not aware of any language changes (like range-over-func) coming in patch releases, it makes the most sense in my mind to use the language version.

This has the advantage of not forcing every downstream consumer of your module to bump every time you change the patch version of your go.mod for no real reason (I understand you're not saying that people should do this, only that you think a patch version is required).

As for the CI stuff, thank you very much for bringing it up. I'll definitely have a think about it but it feels like addressing this patch disagreement first seems the best.

If you have any further reading about the necessity of patch versions in the go directive, please, please, please point me to it. Each of your well-researched comments of mine above were born out from me searching for this information. My decision to pin the go directive to the language version was primarily driven by looking at other large Go projects and seeing at least some of them behaved the same as I anticipated.

Cheers!

I think this topic is slowly killing me. 😅

Hehe, can fully understand that 🙃.

In regards of the patch version as go directive, I decided to ask the expects.
👉 golang/go#68971
Lets see what they say about that.
In fact, a simple go 1.23 will fail, while go 1.23.0 will not.
Assuming (to me) that the docs are outdated (of course, we are devs, docs are always outdated).

Since I'm not aware of any language changes (like range-over-func) coming in patch releases, it makes the most sense in my mind to use the language version.

What would you expect from go in case you use the language version?
Should it always download the latest patch version (based on the language version)?
Therefore, "each time" you run any go command, it wil do an HTTP request, checking if you're up-to-date? 🤔
("Each time" = maybe this can be smarter like caching this value for 24 hours or so).

My decision to pin the go directive to the language version was primarily driven by looking at other large Go projects and seeing at least some of them behaved the same as I anticipated.

Did you looked at projects that are actual modules, so a small piece of software that can be included by someone? 🤔
If so, maybe you looked at projects that have a go directive lower than 1.21 and therefore "working correctly", as versions before 1.21 are allowed to use a non-patched version... 💭
And of course, they use an lower go version because this defines the minimum required go version now. Increasnig that, will limited to consumers of this library quite a lot...

Small update:

Seems that is related (haven't read it yet):
golang/go#65631 that leads to golang/go#62278

In regards of the patch version as go directive, I decided to ask the expects.

Thanks! I appreciate you asking this question. I understand why go: 1.22 and no toolchain results in an error (because the toolchain is required to be a toolchain name as per the syntax):

ToolchainDirective = "toolchain" ToolchainName newline .
ToolchainName = string | ident .  /* valid toolchain name; see “Go toolchains” */

What would you expect from go in case you use the language version?

That's a good question. In our particular usage, I would only expect the toolchain to be downloaded and it has a specific patch version. The go directive would only be used to ensure language feature usage is valid.

In the case of go: 1.22 and no toolchain, I'm not sure what reasonable behaviour is.

Did you looked at projects that are actual modules, so a small piece of software that can be included by someone? 🤔

I think in an earlier comment I linked to etcd but you can look through https://github.com/search?q=path%3A**%2Fgo.mod+%2F%5Ego+1.22%24%2F&type=code

I understand why go: 1.22 [..] results in an error

Well, they changed that behaviour in 1.23, 1.22.4, and 1.21.9 🙈
This is not an error and using a language version in those (and future) versions is not an error.
They decided that in case you specify and langauge version as go, but not toolchain, to download the 0 (zero) patch version.

See golang/go#68971 (comment)
that leads to golang/go#62278 (comment) and golang/go#62278 (comment)

So using a language version in go is not possible in 1.21.0 -1.21.8 and 1.22.0 - 1.22.4.
In other versions it works again and download the 0 (zero) patch version if no toolchain is declared.

This also answers my question:

What would you expect from go in case you use the language version?

It will download the 0 (zero) patch version as toolchain.

Because, in fact, if no toolchain is declared, it will use the go declared version as toolchain.

Still, the question is "using a patch version YES or NO?".
I asked this in my golang issue and they answered:

The release versions are expected and generated by go tooling.

The release versions (starting with 1.21) including patch versions.
There is no 1.21, 1.22, and 1.23 release versions.
So they want that people using a patch version!

In general the issue golang/go#62278 is quite interesting to read.
On mentioned (can't find it right now) somehting like:

The confusing is clear, before 1.21 they forced you to use a non-patch version, after that release, they forced you to use a patch version

This is of course 100% confusing for everyone.

With that being said, I guess the github/cli/cli go.mod file is doing fine by declaring 1.22.0 🙃

Agree?

I'm happy to discuss the next chapter of that toolchain 🤓
But I'll leave it out for now to not mix stuff.

As for the CI stuff, thank you very much for bringing it up. I'll definitely have a think about it but it feels like addressing this patch disagreement first seems the best.

I've also spent too much time thinking about this 🙃, here's a relevant issue in setup-go actions/setup-go#457, the CI output in this repo also includes a bunch of tar errors which are also related to the toolchain handling actions/setup-go#424

Thanks so much for the investigation @StefMa. If the go tooling produces patch versions I'm happy to know that the CLI is fine as it is. I think the most important thing generally is that the go version isn't bumped simply to "move to the latest version of Go" because of the effect it has on all downstream consumers.

So with regards CI, I guess the primary complaint is that we're downloading 1.22.0 because setup-go is using the go directive in the go.mod, and then immediately after, go is respecting the toolchain directive and downloading 1.22.5. This seems to be the issue @matthewhughes934 has raised here: actions/setup-go#457

Was there anything I missed?

I think the most important thing generally is that the go version isn't bumped simply to "move to the latest version of Go" because of the effect it has on all downstream consumers.

This is something I mentioned in my initial description of this issue 🤓.
I think the CLI itself can "always use the latest version" as this is an "end-product".
The CLI act as a, well, CLI and not as a module that can(should?, is intended to?) be imported in another go module.

So in my hoenstly opinion, youre fine to use the latest version in the go line.

If you don't want/like this (because maybe someone else uses this CLI as a module and you don't want to annoy them), you can keep it like it is of course.

But this leads to another question/suggestions/improvement in my initial description issue.

If you want to stay at 1.22.0 to keep backwards compatibily, but still want to enjoy reproducible builds as well as a streamlined developer (and CI) workflow, pointing the toolchain "always moved to the latest version".
With that you can make sure that you enjoy faster compile times, using the same go version across the ecosystem, etc.

Being said, toolchain can now be moved to 1.23.0 on the CLI 🤓.

Or, you can simply say "I don't want to turn my head around toolchain", this drives me crazy, you can also go ahead and remove the toolchain line in the go.mod file. As using 1.22.0 in the go statement will automatically use 1.22.0 as a toolchain as well.

To summarize:

• Either only go "pointing always to the latest release"
  • Benefit: You enjoy always the latest and greatest
  • Downside: You don't maintain backward compatibilty with consumers of the CLI.
• Use go pointing "to your minimal support go version" PLUS using toolchain
  • Benefit: You enjoy always the latest and greates in regards of compiling, you have a streamlined go version across the ecosystem
  • Downside: You can't always use the latest and greatest features as you have to maintain go 1.22 as the minimal support version

Final summary:
I guess youre fine what you have right now.
Maybe toolchain can be bumped to 1.23.0 or removed completely 🤷
I would prever to bump it, but that is not my decision.

So with regards CI, I guess the primary complaint is that we're downloading 1.22.0 because setup-go is using the go directive in the go.mod, and then immediately after, go is respecting the toolchain directive and downloading 1.22.5. This seems to be the issue @matthewhughes934 has raised here: actions/setup-go#457

That is exactly the point, yes 🙃
But unfourtnaly it seems no one from github takes care of this 😭
Maybe you can raise this problem to someone at github 😉

Feel free to close this issue aftwards.
And thank you for this nice discussion and back and worth.
Much appreacheated it.
I learned a lot ❤️

The CLI act as a, well, CLI and not as a module that can(should?, is intended to?) be imported in another go module.

Sometimes people do important parts of the module: https://github.com/search?type=code&q=path%3A**%2Fgo.mod+%22github.com%2Fcli%2Fcli%22

There's not really an intention to support or not to support this. Personally, I wouldn't have a problem making breaking changes in the cli module to improve our lives, but I also don't want to make life harder for anyone else unnecessarily.

Being said, toolchain can now be moved to 1.23.0 on the CLI 🤓.

I'd be happy to have a PR for that, please open one if you'd like to. I don't want to bump the go directive because ^

But unfourtnaly it seems no one from github takes care of this 😭

I'll see what I can do here. I'm sure people care but I know the folks in actions have a lot on their plate.

Thanks for all the conversation and investigation here to bring clarity.