description = "After my previous post on using a `Makefile` to set version and build info I got some valuable feedback from other Gophers. Here's an update."
slug = "building-golang-cli-tools-update"
+++
In my [previous post][previous] I discussed how to use a `Makefile` to set version and
build information at compile time. Although this approach may work fine for you, it has
three drawbacks I want to discuss.
### 1. Simplicity
Andrew responded on the [golang-nuts mailing list][golang-nuts] with the following comment:
> To me it seems like you took something simple and cross platform "go generate" + "go install/build" and turned it into something more complicated and less portable.
Although I'm not sure `go generate` is relevant in this case, I agree that on some level
a `Makefile` is complicating things unnecessarily. Let's remove it!
### 2. Non-reproducable builds
Guilio responded with:
> I only have an issue with buildTime: it makes the build not reproducible.
This is a valid point. The idea that if you compile a given version of your application,
the resulting binary's hash (be it MD5 or whatever) should be equal to that of any other
binary build from that specific version.
By using `BuildTime` the binary is never the same.
Build time is also irrelevant. It does not matter _when_ a binary was compiled, but it
_does matter_ which precise version was build.
Let's replace `BuildTime` with the current git commit hash instead.
### 3. Why is there a `VERSION` file?
If you're going to store version information under version control, you might as well
put it right in the code, where it belongs.
Let's remove `VERSION` and instead create a nice `version.go` to handle everything.
## Let's refactor
Okay, first things to go are `Makefile` and `VERSION`.
Next, I created a `core/version.go` which contains the necessary version information.
I've also taken the liberty of creating a proper struct for the version information,
including major, minor and patch numbers, as well as a label and release name.