bradfitz
commented
4 years ago If others want to see what's available, you can try:
diff --git a/version/version.go b/version/version.go
index 1bc61d6..3a2562e 100644
--- a/version/version.go
+++ b/version/version.go
@@ -7,5 +7,24 @@
// Package version provides the version that the binary was built at.
package version
-const LONG = "LONGVER-TODO"
-const SHORT = "SHORTVER-TODO"
+import (
+ "fmt"
+ "os"
+
+ "rsc.io/goversion/version"
+)
+
+var LONG = "VERSION-UNKNOWN"
+var SHORT = "VERSION-UNKNOWN"
+
+func init() {
+ n, err := os.Executable()
+ if err != nil {
+ return
+ }
+ v, err := version.ReadExe(n)
+ if err != nil {
+ println(err.Error())
+ }
+ println(fmt.Sprintf("Version: %+v\n", v))
+}Then go run ./cmd/tailscaled -h.
danderson
Foxboron
apenwarr
DentonGentry
When we do tailscale binary releases, we stamp version info into the binaries with the Go linker.
But for people just using "go get" the default way, we don't have that info.
Since Go modules, we at least see the summary of all our deps (and Go's version itself; I'm running a devel build) automatically stamped into the binaries:
We can get that at runtime (using https://godoc.org/rsc.io/goversion/version) but for better or worse, that doesn't include that the Git hash of the top-level module, only the deps.
So one thing we could do is add a fake dep to another module (like github.com/tailscale/version-horizon) that we have a bot auto-advance every $INTERVAL, so at least we have a rough date range of what binary people are running when they're running unofficial binaries. Or, if we're already having a bot do this, avoid that indirection and just have the bot auto-commit the latest date to version/version.go every $INTERVAL instead.
Low priority, but we'll probably want better data in the future.
/cc @apenwarr @crawshaw @danderson