Daniel Martí

A thought: if we're only concerned about having a reliable way to _always_ get _some_ useful version for the main module, I think it could be an API of its...

@4ad the "VCS fallback" mentioned in my proposed API could still resemble a pseudo-version, in the sense that it could give you some semver information related to the last known...

> provided there's a way to retrieve it from outside the binary Do you mean via a cmd/go command that takes a path to a binary, or via a Go...

It would be a "fake local" version similar to a pseudo-version; we haven't defined what the format of that would be yet. I think we're all in agreemnet that it...

> But this is not easily portable between users of the project, because often these directories can be re-created on the user's machine and aren't even checked-in. Asking people to...

> Could you elaborate on why do you think it's bad? It may not be the most elegant solution, but it's common practice, well-understood and somewhat expected. The common practice...

On #44203, @jayconrod said: > Though I think we should talk about allowing `@version` on all commands that take packages (where it makes sense; not `go generate`). If the plan...

> go install -o $(go env GOBIN)/gopls-master The downside of that is that it depends on POSIX Shell syntax, so it wouldn't be portable to e.g. Windows. I see little...

Maybe. The flip side of the coin is that `go install -o` would make little sense, since `go build -o` would be much clearer :)

@rlanhellas subscribe to this thread; you'll get notified when there is an update. This is not in the immediate roadmap, given that we're in a code freeze for 1.18 for...