go: install go1.16beta1 in go1.16beta1 directory

[hyangah]

On arm CPU, the go formula uses 1.16beta1 with the version 1.15.6 - because M1 support is available only from 1.16.

homebrew-core/Formula/go.rb

Lines 7 to 10 in 736c68b

	if Hardware::CPU.arm?
	url "https://golang.org/dl/go1.16beta1.src.tar.gz"
	sha256 "48e032c8cf71af4dc8119a29ee829c4fbd5265e32fd012564d4a70bb207695c1"
	version "1.15.6"

I understand the intention, but this caused great confusion while debugging 1.16 issues like

golang/vscode-go#1087

Please consider using the true version name.

[carlocab]

This is explained if you do brew info go:

homebrew-core/Formula/go.rb

Lines 89 to 100 in 736c68b

	def caveats
	s = ""
	if Hardware::CPU.arm?
	s += <<~EOS
	This is a beta version of the Go compiler for Apple Silicon
	(Go 1.16beta1).
	EOS
	end
	s
	end

[hyangah]

I understand, but this version string appears in various go command logs and outputs (go env for example), and it's distracting.
I had to explain to various go maintainers that this is a lie multiple times. All this slowed issue triage.

On the other hand: we are very close to go1.16 rc release - I hope that can be installed with the true version string directory path.

[carlocab]

this version string appears in various go command logs and outputs (go env for example)

Why is it doing that? Is the version string being parsed from the Cellar path? I don't think you should be doing that, as I'm not sure the Cellar path is considered a public API.

In any case, if you would like this fixed, please open a PR so that it can be reviewed properly. Note that the version string cannot contain the word "beta" or else our CI will reject it.

You may also wish to read this for context on why the version is listed wrongly: #67665

[hyangah]

@carlocab we are not parsing version string from the directory path. But, still humans who read the trace and bug reports get distracted by the version string embedded in the directory path.

[hyangah]

If the CI can't be fixed to accept prereleases, I don't see a reasonably easy path forward :-(
go1.16 release is very close and I hope this is a rare situation that shouldn't happen again soon.
Should we just leave as it is now for another month? @fxcoudert @FiloSottile

[fxcoudert]

I apologize for the choice of "lying" in the version number, it was deemed the lesser of two evils, really. Hopefully go1.16 is released soon and this is all behind us!

[carlocab]

I guess the version string could be changed to something like 1.15.99 to avoid confusing it with the non-beta 1.15.6. However, I don't want to force the ~90,000 downloads of go in the last month to reinstall it, so the new version string will only apply to future downloads of go. Given that the new release is going to be soon, it may not be worth it.

[carlocab]

Actually, arch-dependent versions don't work, so even if CI would accept a beta version, changing the listed version won't help: #68946 (comment)