Introduce CLI version option

[au-phiware]

Prior to this change, gomacro was unable to report its own version.

I found myself reaching for the version when experimenting with my own changes, so I added a --version.

This change introduces the cmd.Version package variable and Cmd.Version method, together these print the binary's version, which can be injected at build time. The -V and --version options are now recognised by the cmd.Main method and these options, as well as -h and --help, short-circuit all other options on the command line. This avoids evaluating any possible expressions and the like if the user just wants a quick version or usage message.

When I install the binary from source I now use:

go install -ldflags="-X github.com/cosmos72/gomacro/cmd.Version=$(git describe --dirty)"

And that produces:

$ gomacro --version
gomacro v2.7-454-gff4eff9

I don't know if you've thought much about setting up a release process. I've heard that go get doesn't work with go modules (not sure where I heard that, but it works for me). In the past I've done this sort of thing: https://www.devroom.io/2015/10/12/building-golang-cli-tools-update/. And goreleaser looks interesting...

You can even pass build flags to go get (which seems weird to me), so you could update the install instructions to:

go get -u github.com/cosmos72/gomacro -ldflags="-X github.com/cosmos72/gomacro/cmd.Version=$(date --iso-8601)"

But if you ask me I think it would be nice to use goreleaser instead... I'd be happy to explore it in more detail if you think it's worthwhile. Not that your intended audience needs easy access to a binary, presumably a user won't be installing gomacro and not have go installed already...

Perhaps the hardcoded value should be "v2.7" instead of "latest" (and you can bump it when you decided to bump the tag)?

Sorry, for for the meandering train of thought here; anyway, I hope you like this idea :)

[cosmos72]

I like the idea of adding a command line option "--version".

A mechanism to automatically inject the version numbers would be preferred, though:
Maybe a git checkout hook (I think it's called "smudge") that modifies cmd/cmd.go on the fly ?

I want to keep the installation as simple as possible, and the current installation instructions go get github.com/cosmos72/gomacro are as simple as it gets.

[au-phiware]

I don't think a smudge filter will work because it would require the user to set it up prior to running go get and I wouldn't expect anyone to do that... Using a pre-commit hook in conjunction with git describe is problematic because you can't tag a commit before it exists which means git describe won't be in lockstep with your version when you need it to be. A GitHub action could be setup to automatically tag the repo based on the value of cmd.Version when the commit changes it, which would save you from remembering to tag after changing the value. But once you venture into GitHub territory it might be better to use something like goreleaser. BTW, I like that you've only tagged with major.minor, it means that the number of additional commits shown by git describe forms the patch portion of the version string.

Using go get as the install procedure assumes that the user has already installed go and their PATH is correctly setup. Gomacro can actually run without go installed, I'm not sure if anyone would actually want to do that but, personally speaking, the simplest software to install is the one that has a static binary available to download; a single wget or curl to a path of my choosing and it's installed. But it does make it more complicated for you as the publisher of the software.

I'd love to be wrong about smudge... I've never really understood how dirtying the working tree immediately on checkout is useful.

I pushed one small amendment so that the hardcoded version is now "v2.7", which I think makes a bit more sense when using go get for installation.