modules: what should the language field show for various types of release?

[myitcv]

https://cuelang.org/cl/1176194 added support for a language version in cue.mod/module.cue:

module: "main.org@v0"
language: {
	version: "v0.1.2"
}

cue mod init automatically adds this field, and cue mod tidy adds it if it is missing.

The question however is what to do with the various kinds of releases/builds of CUE?

• Official (pre-)release distributed via this repo, e.g. v0.8.0, v0.8.0-alpha.1
• CUE built from a commit/tag/etc via go build
• CUE installed from a version/master via go install cuelang.org/go/cmd/cue@$version
• ...

This issue is a placeholder for making sure we are comfortable with our answers in these various scenarios.

See discussion in https://cuelang.org/cl/1176732 for more background. This surfaced via v0.8.0-0.dev appearing in the preprocessor output from the automated version of the modules tutorial.

[mvdan]

I'm comfortable with the current behavior as-is, for what it's worth. It seems to be:

1. For released binaries, or any tag installed via e.g. go install cuelang.org/go/cmd/cue@latest, we insert a semver e.g. v0.8.0 or v0.8.0-alpha.3.
2. For commits/branches installed via the proxy, e.g. go install cuelang.org/go/cmd/cue@master, we derive the last git tag from the module pseudo-version. This was v0.8.0-0.dev for the commits immediately following v0.7.0, and as of today's master it would be v0.8.0-alpha.4.
3. For any local git checkout go build binaries, cue version is derived from the stamped VCS information, which at the moment omits git tags (e.g. v0.0.0-20240229185933-77936ec16926). As such, there is no git tag to derive from our pseudo-version, and language.version is not inserted as we don't have a value.

I hope that, once upstream finds the time to work on golang/go#50603, which has been accepted, then case 3 would effectively become equivalent to case 2 - as long as the local git checkout hasn't created extra git tags which haven't been pushed, which should be a very rare edge case we can do nothing about.

[mvdan]

One last point - I think this unease was started by seeing language: version: "v0.8.0-0.dev". We only use such a first pre-release tag immediately following a tag like v0.7.0 so that the first commits with feature work towards v0.8 get a pre-release like v0.8.0-0.dev-timestamp... rather than v0.7.1-timestamp.... The latter is somewhat wrong, as the master branch is now tracking work for v0.8, and if we were to do a v0.7.1 tag from a release branch with cherry-picks, then master could "upgrade" to the bugfix release.

This is all working as intended in terms of tagging v0.8.0-0.dev and such a version potentially ending up in language.version. That said, if we don't like the name of the tag, which is only meant to convey "this is a development version of v0.8 before any alpha release", we can always use a different tag naming scheme like v0.8.0-alpha.0 or whatever else. The only thing that truly matters is that -0.dev sorts less than the first alpha release, -alpha.1, per the semver spec, which splits by dot and then does a numeric or string comparison.

[mvdan]

With @myitcv and @rogpeppe we are happy with the current status described in #2811 (comment). Having local builds of cmd/cue not know their own version is relatively bad, but we can't do anything about it right now until upstream improves version stamping of local builds, so I raised #2908 as a tracking issue.