cmd/dist, x/build/cmd/golangbuild: switch to a devel version format that satisfies go/version.Lang and go/version.IsValid in more cases

[dmitshur]

golangbuild currently generates VERSION files with strings like this, a behavior that the Go build system had for a while:

devel <commit>
devel <change>/<patchset>

Which is broadly based on make.bash's auto-detection logic used to construct a version when a VERSION file specifying it isn't present, which generates version strings in a similar format (the "go1.X-" prefix being new as of CL 264938):

devel go1.X-<short commit> <date>

That format satisfies the property that a "devel" substring is present, but not the property that go/version.IsValid is true and go/version.Lang works on it.

As motivated in #73369 (comment), I suggest we change to the following format that have all of the aforementioned properties:

go1.X-devel_<commit>
go1.X-devel_<change>_<patchset>

Where go1.X corresponds to the language version specified in internal/goversion.Version, something golangbuild has easy access to. Something to consider including .0 like go1.X.0-devel_..., but given the first pre-release version (e.g., go1.25rc1) leaves it out, maybe its fine to leave it out too. Since this is just a development version which isn't tagged or published anywhere, changing it if we find a need to shouldn't be too expensive.

There might be test cases or other code that relies on the current format, such as checking for "devel" prefix (or its absence), that'd need to be updated as part of this.

CC @golang/release, @prattmic.

[gabyhelp]

Related Issues

• proposal: start using semantic versions for Go releases #32450 (closed)
• cmd/go: include Go's base version in its devel version strings #44960 (closed)
• proposal: cmd/go: Use `git describe` output as canonical version string #21209 (closed)
• x/build: builders write a custom VERSION file with a simple "devel {hash}" format when testing Go #42221 (closed)
• go build should remove semantic versioning when determing file name #29643 (closed)

Related Code Changes

• cmd/dist: include "go1.x-" in devel go version strings
• cmd/compile: accept -lang=go1 as -lang=go1.0
• [release-branch.go1.23] go/types, types2: only use fileVersion if 1.21 or greater
• cmd/go: introduce the GOVERSION env variable

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

[prattmic]

I am perfectly happy with the go1.X-devel... format, but I feel fairly strongly that golangbuild should generate a version in the same format used by cmd/dist (https://cs.opensource.google/go/go/+/master:src/cmd/dist/build.go;l=439;drc=b16c04f43993436f24b1e4155a4652193eb1b90c) for standard builds [1].

So this change to golangbuild sounds good if we make the same change to cmd/dist, otherwise it seems we should change golangbuild to be in line with dist.

[1] Why does golangbuild need to generate a VERSION file at all?

[dmitshur]

Yes, agreed, we should apply this to cmd/dist too. Retitled to capture that too.

As for why golangbuild (and coordinator, previously) generates a VERSION file, it does it for a few related reasons:

• cmd/dist's findgoversion logic that creates a devel version with the commit hash can only work if 1) .git directory is present, and 2) a git binary is available. This might not be the case for all builders; they might opt to test a GOROOT tree without the .git directory (if that's faster) and some builders may not have a git binary in PATH.

• Next, it's meant to be a (probably small) optimization: the build system already did the work of figuring out what the commit hash (or change ID/patch set number) it's testing, so it can more quickly write that information down into the VERSION file to prevent the somewhat-expensive findgoversion logic from needing to re-compute the same thing.

• Finally, sometimes the build system has more information readily available, like knowing that what the CL number and patch set is for pre-submit runs. Another aspect is that the current release process leaves a stale VERSION file behind on release branches, which would be more misleading if the build system re-used as-is.