On Github rmunn / presentation-2015
Remember SVN $Rev$ substitution?
It was really useful for version numbers.
Example:
version = "1.0.$Rev$"(Maybe not as useful as all that...)
String parsing to the rescue:
"1.0.$Rev: 374 $" ⟶ "1.0.374"Which looks good in an About dialog.
Makes bug reports much easier to reproduce.
But with a bit of cleverness and string parsing, you could turn "1.0.$Rev: 374 $" into "1.0.374", which was quite suitable for putting into your Help→About box. And when users submit bug reports, it's much easier to figure out what specific revision they were using so you can try to reproduce the bug on that specific revision. Your alpha testers give you much more useful bug reports!Git doesn't have nice, numeric revision numbers.
It has ugly-looking commit hashes like 8fb4da5.
$ git describe
v1.0-42-g8fb4da5
v1.0
Latestgit tag
-
42
Commitssince tag
-
g8fb4da5
Hash ofHEAD commit
This means we're 42 commits ahead of version 1.0.
Note: only annotated tags will be used.
Use lightweight tags for private tags,and signed tags for releases.
BTW, always use git push --follow-tags:It pushes only annotated tags.
NEVER use git push --tags:Lightweight tags should not leave your repo.
Change the version number in one place,and it changes everywhere.
No more "update version number" commits.Just Tag It™.
Run git describe early in the build process, then use text replacement to put the version number where it needs to be.
It runs git describe and parses the result.
Then you use those in your later build process.
If you're using TeamCity, the tool's outputis in the right format for TeamCity to pick up.
If you're not using TeamCity, you'll need toset up the environment variables youself.
E.g., output the tool's output to a shell scriptand do source myscript.sh
And remember:
P.S. When your needs outgrow this simple tool,the gitversion tool might be what you need next.