Uh? Whoever uses git to access asdf source code ipso facto has access to a chunk of non-trivial unix software, and can be assumed to be able to run a script. For instance, one that appends (SETF ASDF::*REVISION* "1.362-2-g07f9837") to asdf.lisp before it is copied over to its installation path, or otherwise updates the defvar line.
Whoever uses an installed ASDF will thus have a version number.
And if you're using directly it from git rather than from an installed version, youre responsible for what you're using, and you can trivially ensure that the version you're using is no ealier than whatever version you need. [Ensuring that there are no regressions is slightly harder; you might want to invest in some version-pinning technology for reproducible deployments.]
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Gilb's Law: Anything you need to quantify can be measured in some way that is superior to not measuring at all.
2009/9/8 Robert Goldman rpgoldman@sift.info:
Gary King wrote:
Hi Robert,
I didn't know about --tags; please try now and see what shakes out.
That seems to have fixed it:
[rpgoldman-2:~/lisp/asdf] rpg% git describe --tags 1.362-2-g07f9837
We should think more about
http://www.question-defense.com/2009/03/13/software-revision-numbers-with-gi...
This, by the way, was my birthday and therefore some sort of sign of the cosmic unconscious.
I believe that if we were to get your tags into our clones of your repository, we could figure out a way to get the *ASDF-REVISION* set properly.
Yes.
Any reason why we shouldn't just butcher a version number string into the file when we release it, instead of doing the current rigamarole? Or is there a git wizard, who can supply a better alternative?
Well, the tag is in the _released_ file; just not in the repo; that'll be the next step.
I have been pondering this, admittedly from the point of view of someone who is git-illiterate (ilgiterate?), and the more I think about it, the more I like this solution:
(defvar *asdf-revision* "1.362")
This has the immense advantage of simplicity going for it. The alternatives that I gather from reading Linus, et al. all seem ill-suited for the CL world. They seem to rely on (1) source to source textual translation /outside/ the lisp environment (e.g., Linus proposes to push the version number from git tags into into the Makefile) and (2) easy access to the standard unix toolchain (make, perl, git). But access to the unix toolchain, portably, from CL is not a nice thing, and it doesn't come cheap. Worse, getting this right relies on some tricky logic to detect the fact that you're running from a git working directory (so you haven't had textual substitution performed during the export process), and so need to take an excursion through git-describe.
I'm OK with coming up with an elegant solution that fixes this automagically using git tagging, git describe and so on, but until the messiah comes, how about we do the dumb thing and just stick in a string constant?*
"Il meglio, e l'inimico del bene" [the best is the enemy of the good] --- Voltaire
*If you want, you could make a shell script that wraps around the git tag command, incrementing the release number, pushing the release number into the *asdf-revision* defvar, committing the change, and then applying the tag. That would be pretty much automatic, but the logic wouldn't have to be replicated everywhere that asdf is loaded.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel