Consider running our own module proxy

[dominikh]

Via meta tags, we can define our own module proxy that go mod download should use. This is interesting to us because we're not using semver; we're stuck with pseudo versions. If someone runs go get honnef.co/go/tools/cmd/staticcheck@2019.1, then this will be converted into a pseudo-version of the format v0.0.0-<timestamp>-<commit sha>. If the user later ran go get -u, they'd be bumped to the latest commit on master. Furthermore, a go get with no version specified would also fetch from master. If we ran our own proxy, then we could synthesize our own list of versions, consisting solely of pseudo-versions matching our releases. As long as our list isn't empty, go get [-u] will consult the list and choose the latest element on that list.

The obvious downside is that we would have to maintain more infrastructure.

[dominikh]

An in-progress demo implementation of a proxy: https://go-review.googlesource.com/c/mod/+/176541
Fun with infinite loops: golang/go#31458

[dominikh]

Writing a module proxy is more effort than it is worth. Also, it has been pointed out to me that pre-releases are a thing, and that we can use tags such as v0.0.0-2019.1 for our not-quite-semver releases. As long as we don't have any actual semver-tagged releases, these pre-releases will sort correctly, prevent go get from defaulting to the master branch, and achieve everything we would've achieved with the proxy.