Version string in released binaries is missing the "v"

[johananl]

The binaries we release in official releases print a different version string than binaries built from the same Git tag using make. Building a binary from a certain Git revision should have a deterministic version string baked into it. It shouldn't matter exactly which command was used to build the binary.

Steps to reproduce:

wget https://github.com/kinvolk/lokomotive/releases/download/v0.5.0/lokoctl_0.5.0_linux_amd64.tar.gz
tar zxvf lokoctl_0.5.0_linux_amd64.tar.gz
./lokoctl_0.5.0_linux_amd64/lokoctl version

Output: 0.5.0

git clone https://github.com/kinvolk/lokomotive.git
cd lokomotive
git checkout v0.5.0
make
./lokoctl version

Output: v0.5.0

@iaguis @surajssd - your fingerprints are around this part of the codebase so tagging you for attention 🙂

[invidian]

This is because we use

-ldflags "-X github.com/kinvolk/lokomotive/pkg/version.Version=`git describe --tags --always`

in the Makefile.

I think if we tag as v0.5.0, lokoctl version should also print v0.5.0.

I suggest we change pkg/version/version.go to include the v.

[johananl]

Don't we use the same -ldflags trick when crafting releases? I see no reason for using one process for dev builds and another for prod builds in terms of building the binary. Why not use the same go command in both cases and let git describe do its thing? If I'm developing, the version will be something like v0.5.0-3-gabcd123 and if I'm releasing it will be e.g. v0.6.0.

I suspect this is somehow related to the fact that we use goreleaser when releasing.

[invidian]

You're right. We do use -ldflags when building release builds. The difference probably comes from the fact that {{.Version}} macro from goreleaser does not match output from git describe --tags --always.

{{.Version}} documentation explicitly says that v will be stripped. Perhaps we should use {{.Tag}} instead then.

[invidian]

Hm, after re-visiting it, I have concerns about including v in printed version. v in tag indicates that it's a version of the release. Looking at git for example, they use v2.29.2 and 2.29.2 interchangeably.

$ git --version
git version 2.29.2

I may actually consider admitting, that current behavior is actually correct. Release build prints 0.5.0, if you checkout the v0.5.0 tag and do a development build, you get v0.5.0 printed. But it is not the release build as would be done with goreleaser.

I wonder if goreleaser produces reproducible builds...

[johananl]

v usually means "version", so if you say git version v2.29.2 you are saying "version" twice. git v2.29.2 isn't redundant IMO.

Personally I like the v, but officially the v isn't part of the semver string IIRC. Anyway, I'm fine either way as long as we are consistent, and as said above I think we should use the same process for dev builds and release builds to avoid this kind of mismatches.

[iaguis]

Let's create a Makefile tag that uses goreleaser to generate a release but not upload it to GitHub.

[iaguis]

This will happen in the v0.7.0 PR.