I have a project that I track with Git. For the most part I have had no problem with the Git paradigm, but there is one issue that I haven’t quite figured out. Currently, my master branch points to code that will be released at some point. Topic branches are merged into master when they’re ready, and into develop to test that they work with other dev code. (By the way, I tried Git Flow and didn’t like it.)
The problem with this scheme is that builds from master or develop appear to have the same version as the last stable release, because I incremented the version right before tagging a release. I don’t want this–I want unstable code to refer to itself as such! My question: What are popular and/or usable conventions for committing version bumps? Also, what branching and tagging models could be used to avoid this type of situation? I’d love something simple, because my project isn’t large enough to warrant a big Linux kernel-style model :).
You should take a look at how it is done in Linux kernel by scripts/setlocalversion.
Basically, this script tries to guess version from closest tagged commit. If current commit is tagged, this tag is taken as clean version.
If not, it appends current commit short sha to tag to become a version.
If current tree has any uncommitted changes, it may append string “dirty” on top of that.
Note that this is somewhat simplified explanation (in reality it also looks for version numbers in main
Makefile).Some other tools also adopted similar versioning approach, notably u-boot.