proposal: mod: allow specifying "latest" in a way that considers pre-releases too

[rogpeppe]

Currently cue mod get supports @latest, which means "latest stable version, unless no stable
versions are available, in which case latest unstable version".

Sometimes it's desirable to update to the latest version even if it's a pre-release version
and there are existing stable versions.

We could support @tip for this use case.

For example, for some module M, currently if the following versions of M are in the registry:

v1.0.0
v1.2.3
v1.2.4-alpha1
v1.2.4-alpha2

then M@latest will resolve to v1.2.3 because it will never choose a pre-release over a stable release.

This proposal is to allow M@tip to specify the latest version regardless of whether it's stable or not, so M@tip would resolve to v1.2.4-alpha2 in this case.

[myitcv]

cc @mvdan - we've discussed this before from memory, in the context of golang/go#42545

Edit: apologies, I've now seen the Slack thread that gave rise to this.

[myitcv]

Just one point on terminology here. I don't think you mean to use the term "stable". I think you mean to distinguish between pre-release version and release version (I realise the latter does not have a precise name in the semver.org spec). "Stable" implies, according to the semver spec, a major version >=1. That does not necessarily apply to the query you are looking to specify. Because it's possible distinguish between a pre-release version and release version of a v0 version: e.g. v0.1.0-alpha.1 and v0.1.0.

I'm also not clear that tip is the best name. It implies a VCS, specifically the commit at the tip of the default branch. But that is not necessarily what the latest pre-release version is (indeed given the registry setup it almost certainly isn't unless someone is pushing pre-release pseudo-versions for every commit).

One further question, @rogpeppe. What should these queries look like when the major version number is involved? For example, if I wanted the latest pre-release of v2?