Closed SiteRelEnby closed 8 months ago
This is really cool, but I'm a little confused why it takes so much code to put git describe
into version.h
. I took a quick stab at it and it only required a few lines, so I think I must be missing something.
I uploaded some commits which use git describe as the version, and a helper script to generate release files. For example, since I haven't added a new tag lately and it has been a while and I have local changes, it does this:
> g st
Changes not staged for commit:
modified: ChangeLog.md
> make clean ; make
...
> cat .build/anduril/version.h
#define VERSION_NUMBER "2023-10-31-102.1"
> make release
-rw-r--r-- 1 selene selene 889029 Dec 1 18:33 releases/zip/anduril.2023-10-31-102-g6559665-dirty.zip
>
Does this do what you need, or are there more things required for the way you do releases?
It's more just in flexibility of doing many things like being able to track back to specific releases rather than relying on specific repo state, I have no problem scaling it back though. Probably ended up overthinking it, had a lot going on recently.
At the moment this defaults to not doing anything differently, but when the build supports hexadecimal in version numbers then this can be easily switched over.
New repo-based version number scheme example:
<model code>-2023-10-31[-61[-1][-b1dbfc5]]
(parts in[]
may or may not be present)2023-10-31
: Date of the latest release this build is based on61
: If present, number of commits visible since latest release1
: If present, indicates the build was with the repo in a dirty state. Only possible to appear if-61
part is presentb1dbfc5
: Commit hash of the current commit. Only possible to appear if-61
part is presentAlso various additional small improvements to make script