This is a problem because the builds will end up with an entirely different version format.

Why this is a problem?

I have a custom VERSION file on my GOROOT and it worked just fine.

See #41116, and in particular #41116 (comment).

I don't think there's anything wrong per se, but if tools want to start parsing information from go version or go env GOVERSION, we probably want to be careful with VERSION files containing arbitrary strings.

Thanks. I agree that if tools want to parse Go version, it needs to be careful about arbitrary version strings. I don't think we want to disallow arbitrary version strings, though (it may not work for some tools, and that is probably fine).

I personally don't have a horse in this race - I never create my own VERSION files, and I'm more than happy to have the tools I author simply error when a version string uses a custom format. The suggestion was by @heschik, so perhaps the need comes from gopls. cc @stamblerre

If we want to have a discussion about whether it's a good idea to require the major version I think that belongs on #41116, not here.

It was @dmitshur who requested a new issue be opened for the builders :) I personally prefer keeping discussion in the original issue.

This issue should be about determining what needs to be done on the builder side to support changes for #41116, if anything, and doing it. CC @golang/release.

There's more than one place in x/build that constructs a custom VERSION file, mostly related to debugging via gomote. I think those can be dealt with later.

The one that's relevant to testing commits is in buildgo.VersionTgz. It's used by cmd/coordinator in the buildStatus.writeGoSourceTo method, which has a lot of relevant information. From a relatively quick look, I don't see that the major Go version is computed there though.

Developers using toolstash also use custom version files in cases where you want to compare already-checked-in changes, see toolstash#hdr-Version_Skew. In case that matters.

Thanks @cherrymui and @thanm for helpful context.

After looking more into this, I left a comment on CL 264938 suggesting that it should not expect there to be any requirements met if there exists a VERSION file, since that file is allowed to have arbitrary content. It would be a problem not only on builders, but for users who have a custom VERSION file.

We may still want to change the custom VERSION file that builders write in the future, but I don't think we need to do anything now to unblock #41116 specifically.

I don't think there's anything more to do here, so closing.