For end users I strongly recommend distributing a binary. That gives you the ability to tag it properly and to know what goes into it - your code, your dependencies, and the compiler used. Typically this would happen by vendoring and using a Makefile or build script in the repo, running on some trusted CI platform.
If your end users really should build it themselves, I would have a build process that describes downloading the code, putting it in the correct place (...), and using your build script / Makefile. The resulting binary should know what it is (i.e., what hash it came from and how it was compiled) and be able to report that to you. "go get" is a development tool. It does none of the things you need to happen in a "real" build for end users (imho, ymmv, etc). I would default your VERSION variable to something like "unsupported-dev" and treat the binaries correspondingly... "go get" is still perfectly fine for initially grabbing packages and developer tools where you don't particularly care what version they are. I sometimes use it as a shortcut for mkdir+git-clone for non-Go projects. :) //jb > On 5 May 2017, at 14:09, mhhc...@gmail.com wrote: > > Hi, > > For a program i provide a pre build binary built with > > go install --ldflags "-X main.VERSION=$VERSION" > > So when users met a problem they can report the version easily > and certainty. > > the version variable is set by default to "0.0.0", could be empty string. > > What should be the cmd line to give the user so that they can go get, > and set the version to the git hash using the build flag ? > > From my computer i could do, > > go install --ldflags "-X main.VERSION=`git log | head -n 1`" // or similar > > because i have the repo locally. > > But for an end user which did not clone it locally, > how could that happen in one cross platform command line ? > > Note that i might > - hardcode it into the README or godoc, but that require an additional > control to generate the file containing the instructions, > - or manual update. > > First solution is available only for those who uses such tool, not everyone. > Second solution is prone to errors. > > thanks. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
