On 6/28/16 Jun 28 -7:19 AM, Jan Moringen wrote:
Hi.
It seems to be a common pattern to maintain a project's version information as a string in a separate file, e.g. version.sexp, and use something like
(:version (:read-file-form "version.sexp"))to get that information into the system definition. This seems like a good thing to do as long as version changes are rare and performed manually. Unless there is a better way for this simple case, no problems or questions so far.
There are, however, situations in which this doesn't work. My use-case is a project which is maintained in a GIT repository and uses the following versioning scheme
MAJOR.MINOR.NUMBER-OF-COMMITS-SINCE-RELEASEThis is useful for things like bug reports or determining compatibility of input files with the current version of the software. The crucial part is maintaining NUMBER-OF-COMMITS-SINCE-RELEASE automatically.
Previously, I implemented this behavior using some horrible hacks that I would rather not talk about. I started from scratch and came up with a potential solution (detailed description attached).
Since this seems like a common problem, I would like to ask whether the outlined approach is the proper way to do this. If so, I can try to turn the description into something that could be added to the FAQ section of the ASDF manual.
Thanks in advance and kind regards, Jan
I only had time for a quick look at this, but it did suggest a couple of questions:
1. Is it necessary to have rsb-version write the version-string.sexp file? Could you simply override the COMPONENT-VERSION generic function and compute it on the fly from git and version.sexpr?
2. How does this work across developers? Couldn't you end up in a situation where two developers have versions x.y.z and x.y.z' where z = z' but the two systems are different (because they are on different git repositories with differing histories)? In an ideal world, the version identifier should identify a unique state of the codebase, yes?
I suppose one could get the version identifier from some shared history (like the remotes/origin branch).
3. Your rsb-protocol-config system seems quite reasonable. We have done things like this to, for example, invoke "make" to build required non-lisp code.
Hope that helps, r