We need to start versioning Kubernetes.

The base of it is creating annotated tags (git tag -a ...) every time we want a new release.

I would propose that we release v0.2 now (as soon as we have versioning fixes in place) and put in place a process to tag new releases every so often.

The versioning fixes are mostly about adding version information to the binaries (e.g., for when we call them with the -version argument.) We want to inject version information from git but we also want to be able to build the tree without the git information (e.g. straight go build call, using go get or downloading a tarball without the .git/ tree from GitHub.)

My proposal is to add some information that approximates the state of the tree, such that we can give some version information even if it's not exact. For instance, we'll call these releases v0.2-dev which means, this is somewhere in between v0.2 and v0.3 but we can't tell exactly where, we can't tell whether the tree was clean or dirty (there's no git, so how can we know?) etc.

We could set these up as "fallback" variables in the pkg/version module:

var (
     GIT_VERSION string = "v0.2-dev"
     GIT_COMMIT string = "(unknown)"
     GIT_TREE_STATE string = "(unknown)"
)

Then, for the build from git (using either hack/build.sh or make in the short future) we can inject these variables using -ldflags, e.g.:

go build -ldflags "-X pkg.version.GIT_VERSION=$(git describe) -X pkg.version.GIT_COMMIT=$(git rev-parse HEAD) -X pkg.version.GIT_TREE_STATE=$(...)" ...

I'll send a PR to implement the fallback versions and the ldflags on go build shortly... I don't want to get it merged as a PR though, I'd prefer to just push it as a standalone commit and then tag it with the v0.2 version, making it the official v0.2.

Let me know if you like that plan.

Cheers,
Filipe