proposal: cmd/go: mod init should set patchlevel of go line to .0

[ldemailly]

Proposal Details

follow up on the revert of 1.26.0 go mod init behavior (#77653): keep at least the .0 part of the original 1.26 change
(ie go mod init would always set go line to 1.N.0 in order to avoid churn or the impression this patchlevel must be constantly updated)

[ldemailly]

this is the tame version of #77924

[gabyhelp]

Related Issues

• proposal: cmd/go - go back to 2 digit language version go line in go.mod #77924
• cmd/go: change `go mod init` default go directive to 1.(N-n).0 #74748 (closed)
• proposal: cmd/go: add `-go` flag to `go mod init` #77901
• cmd/go: change `go mod init` default go directive back to 1.N [1.26 backport] #77860
• proposal: cmd/go: change `go mod init` default go directive back to 1.N #77653
• proposal: patch-level for releases & go.mod #56723 (closed)
• build: use a zero for third digit for major release, such as 'go1.21.0' #57631 (closed)
• cmd/go: document that Go 1.26rc1 go mod init creates a 1.24.0 module #76857 (closed)
• cmd/go: decide and document official recommendation for typical 'go' version in go.mod for open source libraries #77830

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[thepudds]

Hi @ldemailly, I think it could be helpful if you could provide a bit more color around why you view this as useful, including with your perspective as an OSS library maintainer (e.g., fortio, etc.), along with some of the pain or struggles you've seen in practice with the current cmd/go behavior and resulting ecosystem behavior.

It could be good to include things that have directly affected you, as well as any observations of problems or issues that you've seen others hit (e.g., maybe as a summary plus a URL for problems you've seen others hit, or just a summary, or however you think best to describe it).

Finally, while I think there are some pros/cons to this proposed change, my questions here are not intended to imply that there is little or no justification for a change like this. I could of course write my own version of why I think this proposed change is useful for at least some people based on what I've observed (and I did in fact do a write-up of some related challenges in #77830), but personally I'm curious to directly hear more of your perspective, and I think that could help others better understand as well 🙂.

[ldemailly]

I rushed this before my dog walk and morning coffee, good idea, let me add more color in a bit (will edit the main description then) - this being said for this one it's mostly about just keeping the .0 behavior which is already what x/ repoes do, and I don't think is very controversial (the N vs N-1 was the controversial part) then it'll hopefully lead to #77924

[howardjohn]

Strongly agree on this, wanted to link https://news.ycombinator.com/item?id=47558581 which has some commentary on both sides of this argument.

[rittneje]

@howardjohn In your blog post, you claimed that using the go directive to drive the GitHub testing matrix was wrong, and to use the toolchain directive instead. But this seems precisely backwards. If you are going to claim to support, say, 1.25.0+, then you need to test it. Frankly, the toolchain directive makes a lot more sense for an application than a library. Especially because the toolchain directive is not considered in a library, and is very unlikely to be observed by the consumer, particularly for a transitive dependency. Also, the idea of a "recommended" version doesn't make sense here: that is always the latest patch version of one of the supported minor version.

Also, describing the go directive as the minimum version that it can compile with is misleading. It is the minimum version the author intends to support. Just because it happens to compile on an older version doesn't necessarily mean it works, and even if it does, that doesn't mean it was the authors intent. In other words, if I for example put go 1.25.0, that doesn't mean Go 1.24 doesn't work, just that it is out of my support contract and may not have been tested.

[howardjohn]

In other words, if I for example put go 1.25.0, that doesn't mean Go 1.24 doesn't work, just that it is out of my support contract and may not have been tested.

Yes it does...?

$ echo 'module f

go 1.26.1' > go.mod
$ go1.25 build
go: go.mod requires go >= 1.26.1 (running go 1.25; GOTOOLCHAIN=local)

Frankly, the toolchain directive makes a lot more sense for an application than a library.

Agreed

But this seems precisely backwards. If you are going to claim to support, say, 1.25.0+, then you need to test it.

While I think this is probably not a bad idea (a theoretical perfect-test-coverage suite would test every Go version, on every CPU, on every OS, in every timezone (just in case!), etc), practically speaking I think most libraries can/should get away with not doing this given how robust Go's backwards compatibility guarantees have been historically

[rittneje]

Yes it does...?

I meant other than the go directive itself. When I choose the go directive, I am saying "this is the minimum version I care to support," not necessarily "this exact code is totally incompatible with a prior Go release."

I think most libraries can/should get away with not doing this given how robust Go's backwards compatibility guarantees have been historically

This has nothing to do with backwards compatibility though. Like any other piece of software, the standard library evolves and can have bugs. Code that works with say 1.26 may not work with 1.25, and there is more to this assessment than just static analysis. And code that works with say 1.25.8 may not work with 1.25.0 if it trips over the very standard library bugs that were fixed.

In many ways, this is no different than any other dependency. For instance, if a library's go.mod says it needs golang.org/x/net v0.40.0, it would be silly to then only test with the latest release of x/net instead.