cmd/cue: the current release/language version should be known for local builds

[mvdan]

Until the accepted proposal at golang/go#50603 is implemented, this is the situation:

$ go install ./cmd/cue
go: downloading cuelabs.dev/go/oci/ociregistry v0.0.0-20240229191153-7fc950808203
$ cue version
cue version v0.0.0-20240304112812-bab5d3a8d1ae

go version devel go1.23-b5a64ba62e 2024-03-01 08:06:08 +0000
      -buildmode exe
       -compiler gc
  DefaultGODEBUG httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v3
             vcs git
    vcs.revision bab5d3a8d1ae6ec55b51e3cee7c96f27d6cbb478
        vcs.time 2024-03-04T11:28:12Z
    vcs.modified false
$ go install cuelang.org/go/cmd/cue@bab5d3a8d1ae6ec55b51e3cee7c96f27d6cbb478
go: downloading cuelang.org/go v0.8.0-alpha.4.0.20240304112812-bab5d3a8d1ae
$ cue version
cue version v0.8.0-alpha.4.0.20240304112812-bab5d3a8d1ae

go version devel go1.23-b5a64ba62e 2024-03-01 08:06:08 +0000
      -buildmode exe
       -compiler gc
  DefaultGODEBUG httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v3

That is, a local build has VCS information, but it doesn't know what semver version it is or it follows, in this case https://github.com/cue-lang/cue/releases/tag/v0.8.0-alpha.4.

This affects cue mod init and cue mod tidy in that not knowing the semver tag means we don't insert language.version: #2811 (comment)

This is a tracking issue; we can't do much until upstream implements the accepted proposal, so I expect this issue will remain open for at least a few months. Still, it's useful to track as a dependency for other issues or sharp UX edges.

[mvdan]

Recently, @rogpeppe and I discussed adding a manual version string to the cmd/cue/cmd package, so that a local build would know what semver version tag it relates to, e.g. v0.8.0-alpha.4.0.20240304112812-bab5d3a8d1ae rather than v0.0.0-20240304112812-bab5d3a8d1ae. At the time I argued it's not really worth the manual work and effort, given that few users should be doing local builds, and that it didn't really impact any significant functionality.

Now that cue mod init and cue mod tidy are affected by this (see above), maybe it is worthwhile to do this. I suggest adding a const versionFallback string, which would be currently set to v0.8.0-alpha.4, to manually track the last semver tag we have done in the branch. From highest to lowest priortiy, we would determine the version as follows:

1. Users explicity setting a version at build time via -ldflags='-X cuelang.org/go/cmd/cue/cmd.version=<version>' would use that version as-is
2. Users building via GOPROXY would get the module version reported by the proxy as-is
3. Other users (i.e. those using go install ./cmd/cue) would get the fallback version manually added above, even if they are currently a few commits after that last tag, since cue version will still print the stamped VCS information

Teaching cue version about whether or not scenario 3 is exactly on a tag is possible, but it would require double the amount of manual work (e.g. const releaseCommit bool), which we would change immediately after every release tag. My impression is that this isn't worth it, and it wouldn't affect language.version either.

[myitcv]

Sounds like a good approach to me. Thanks for the analysis.