go/version: doesn't handle devel toolchain versions

[prattmic]

If I build a binary with a tip toolchain and read the debug/buildinfo out of it, I get a GoVersion that looks something like devel go1.25-9ce47e66e8 Wed Mar 26 03:48:50 2025 -0700.

If I am using go/version to compare versions, everything falls over because go/version considers the above output to be invalid (IsValid() == false), and then Compare sorts it before everything else.

I'd really like this to compare equal to go1.25, so that it also compares greater than go1.24.

[prattmic]

My particular use case is to look at the version of a Go toolchain and decide if it is too old to use for my purpose.

For example, sweet should not try to build typescript-go with a 1.23 toolchain because it requires 1.24 (#73052). We can't just allow toolchain upgrades for old toolchains because the whole point of sweet is to test an exact version of the toolchain. It is also awkward that 1.23 fails to parse the go.mod (../../go.mod:20: unknown directive: tool) before it can decide that it is too old.

[prattmic]

One potential option would be to simply drop "devel" from the version we embed in the buildinfo. go1.25-9ce47e66e8 Wed Mar 26 03:48:50 2025 -0700 is a valid version with exactly the semantics I want.

Unfortunately, just in the Go repos alone there are a worrying number of checks for the string "devel" in versions.

[gabyhelp]

Related Issues

• go/version: unclear as to what counts as a valid Go version #65061 (closed)

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

[dmitshur]

The ability to be able to tell that a given Go version isn't a released version can be useful, and quite a bit of code relies on the presence of the "devel" substring as you mentioned. Instead of removing it, a much smaller change that might be worth pursuing is to simply move it—that way all the strings.Contains(..., "devel")-using checks will be unaffected, and there might be much fewer strings.HasPrefix(..., "devel") instances to update.

In some cases within the build infrastructure, we already construct a version string like go1.X.Y-devel_<commit> or go1.X.Y-devel_<change>_<patchset> that keeps the property that "devel" substring is present but in a format that go/version considers valid:

https://source.chromium.org/chromium/infra/infra_superproject/+/main:infra/go/src/infra/experimental/golangbuild/buildmode.go;l=128-130;drc=d158479cea677154e162ed205706717645e7b437

So maybe we should extend that to apply all other cases, too. That way it's possible to call version.Lang on that to tell the language version.

Edit: Filed a golangbuild-specific issue #73372 for this.

[gopherbot]

Change https://go.dev/cl/668015 mentions this issue: cmd/dist: move "devel" substring in git-inferred development version

[gopherbot]

Change https://go.dev/cl/668355 mentions this issue: cmd/go, cmd/internal/objabi: detect "devel" version by substring

[gopherbot]

Change https://go.dev/cl/669215 mentions this issue: sweet/harnesses: stop trimming "devel " prefix from Go version

[dmitshur]

We've taken the alternative route of making the generated development versions be compatible with the existing https://go.dev/doc/toolchain#name format (as a "non-standard toolchain") in #73372. Is there anything more to do here @prattmic or shall we close this?