Build: add -dev suffix for minikube version on master build

[medyagh]

Feature request:

currently when we build minikube, the binary out/minikube version would return the latest version

$ ./out/minikube-darwin-amd64 version
minikube version: v1.1.1

it would be nice if it lets you know this is a built of master HEAD, maybe have a suffix 1.1.1-snapshot

[djmgit]

@medyagh I would like to take this up.
So what needs to done here is that the final binary that is produced via make should have a suffix like
version-snapshot right?

[afbjorklund]

It is normally called "dev" in these contexts, not snapshot.

Probably a good feature would be to add the git commit ?

Compare:

$ runc --version
runc version 1.0.0-rc6+dev
commit: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
spec: 1.0.1-dev

[medyagh]

I like that format you pasted ! yes that would be great.
we want to make sure also it doesn't break anything including download iso ... (not sure if it would act weird if filename has + in it when downloading from GCS on different platforms including windows)

[afbjorklund]

Yeah, I would probably use - rather than +, but that's another story. In that project they use a version file to set the name, so they can use whatever they want. Also note that we have a lot of subprojects that "assume" they are building from their own git, and thus either fail to record a version or use buildroot's.

So this innocent feature has some implications on the release process...

The first is that you should still be able to build from git. That is, just because I build from master doesn't mean it's a development release - what if I check out the v1.1.1 tag and build it ? The alternative would be tagging on a branch, and then you miss nice features (like git describe)

The second is that you should be able to not build from git. That is, there should be some way to override the information posted - what if you download the tarball and don't even have git installed ? Currently we use something like $(MAKE) GIT_COMMIT=$(THE_COMMIT) to provide the info.

Maybe we can start with adding a second line with the commit, and take it from there ?

$ minikube version
minikube version: v1.1.1
commit: ef60a69700170ace1b20b286cd6fd8d3e8d13277

---

There's already things in that little minimal output, to make people confused...

• why is "minikube" duplicated ? just in case there's another version (like the "spec" above) ?

• should there be a colon before the version ? lots of other programs don't have it there...

• which gets even worse, when programs start screen-scraping the version output...

• ... but then they still add the colon before e.g. the commit, just to make it interesting.

• why does it dump the git tag and not the version ? a.k.a. "the v is silent" (see Silent letter)

• users then gets this wrong all the time, leading to "missing files" or even bug reports (Parsing of Kubernetes version strings is brittle and doesn't display useful error messages #3253)

• should we output the build date ? even though it is useless, and makes it non-reproducible

• or should we use the commit date ? maybe even something like $(SOURCE_DATE_EPOCH) ?

So I think we should start with something small (commit), and take it from there ?

¯_(ツ)_/¯

I personally like "git describe": v1.1.1-20-geba3879

But everything is "possible", even JSON (hello, kubectl)...

$ minikube kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

[djmgit]

@afbjorklund cool, I will create a PR accordingly to display version in the format you mentioned above to get started with.

[afbjorklund]

One additional feature compared to what is described above was the addition of -dirty.

This means that there are local changes to the tracked files, compared to the git commit.

Compare git-describe:

$ git checkout master
$ git describe --dirty
v1.1.1-97-g247efde
$ echo >> README.md 
$ git describe --dirty
v1.1.1-97-g247efde-dirty

Similar to -dev for the release, this means that there are changes since the commit.

But unlike a patch file or something that describes which files, it just records it being "dirty".

[medyagh]

Closed by #4548

please reopen if needed.