This repository demonstrates one way to version go projects.
-
Go binary
To create a Go binary from this repository's source code, just runmake
without arguments in your local copy. Every binary built with this command knows its version number. You can retrieve it like this:$ ./go-versioning --version go-versionining version 0.3.0 build 2106621
-
Docker image
To create a Docker image with the Go binary in it, runmake docker-image
. This will build a Docker image with the output ofgit describe --tags --always
as tag name. This means that when your repository is currently on the revision of tagv0.3.0
, the Docker image's tag will bev0.3.0
. If you add one commit and build the Docker image again, its tag will be something likev0.3.0-1-gabc123
.
Applying the concept of Semantic Versioning, there are three make targets to create releases:
make release-major
make release-minor
make release-patch
Each of these targets increments the respective version number in the VERSION file, commits it, and tags the commit with the correct version number.
Note:
While preparing this setup, I created several releases in order to test the setup itself.
Because I went back and forth between commits and edited things in old releases (which is not a good
practice in general), I added a Make target retag-releases
that makes sure that all git tags
point to the correct release commits. It's probably not a good idea to do this in a real life
project.
- In the current implementation, there is no check that your working copy is clean when executing one of the above-mentioned make targets. This means that you could build a docker image
...:v1.0.0
with changes that are only present on your local hard drive. - Code-Duplication: Having this kind of logic in Makefiles makes it hard to reuse it in other repositories. This could be resolved by implementing it in a separate tool that is just being executed in the Makefile.