Improve the way version numbers are managed, fixes 1207709

[jvehent]

In bug 1207709, we noted that the version string isn't set when installing binaries using go get. This patch sets a base version string the MIG package, which is modified when binaries are built using the Makefile. The trade-off is that we'll need to update the base version string on a regular basis.

$ make
$ for bin in $(ls bin/linux/amd64); do echo -en "$bin: "; ./bin/linux/amd64/$bin -V; done|column -t
mig:                             20150924+11e33fc.dev
mig-action-generator:            20150924+11e33fc.dev
mig-action-verifier:             20150924+11e33fc.dev
mig-agent-20150924+11e33fc.dev:  20150924+11e33fc.dev
mig-agent-latest:                20150924+11e33fc.dev
mig-api:                         20150924+11e33fc.dev
mig-console:                     20150924+11e33fc.dev
mig-runner:                      20150924+11e33fc.dev
mig-scheduler:                   20150924+11e33fc.dev
mig-worker-agent-intel:          20150924+11e33fc.dev
mig-worker-compliance-item:      20150924+11e33fc.dev

@ameihm0912 : r?

[ameihm0912]

r+.

Do we want to use this opportunity to resolve future comparison issues with package managers? In cases where the package needs to be recreated on the same date, the date version string stays the same but the commit hash will change. The current version format results in the commit hash being treated as part of the version string which will obviously fail in certain circumstances.

We could add a "release" component to the version string?

For example, 20150924-0+11e33fc

Subsequent packages with the same version string will result in the integer release value being incremented by one, which will make things like yum/dpkg/etc evaluate the package version correctly.

[jvehent]

That seems like a good idea. What about the format itself? do we want to change it entirely to something more common, like 0.0.0 ? I like the information that the current format carries, but if it's problematic, I'm not opposed to changing it.

[ameihm0912]

I don't think its problematic as long as we make there the leftmost values provide enough information to determine the version prior to getting to the commit hash (e.g., before we read the + and on, we can already assert if the package is newer or older then the installed one).