Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Eric Bavier <ericbav...@openmailbox.org> skribis: >> >>> I realize we have no guidelines in the manual concerning the version >>> field for git checkouts, but I wonder whether we should, as it comes up >>> a bit. Several existing packages use (string-append "1.2.3." commit), >>> where "1.2.3" is the version of the corresponding source. One other >>> package uses the (string-append "1.2.3-c" commit) method, and another >>> uses (string-append "1.2.3-" commit. I personally prefer the "-" >>> notation, since it distinguishes the commit hash from the version >>> number (does it confuse any internal logic that assumes a package >>> version number is the last component of the store path following a >>> dash?). In this case, the "-c" seems confusing because the commit hash >>> itself begins with a 'c'. >>> >>> I recall some discussion previously about how it would be nice for >>> git-checkout package versions to still "sort" nicely. >> >> I think the goal should be to ensure lexicographic ordering, such that >> ‘guix package --upgrade’ DTRT. >> >> In practice, that means the (string-append "1.2.3." commit) should be >> avoided. >> >> Instead we should use (string-append "1.2.3." REV "." commit) where REV >> would be an integer we manually increment every time we upgrade to a >> newer snapshot. > > I'd like to propose another alternative, which I used for 'grub' on the > 'wip-loongson2f' branch. There, the version string is simply the output > of "git describe". This gives us lexicographic ordering, and the commit > id can be extracted with (last (string-split version #\g)). > > So, it ends up looking like this: > > (define-public grub > (package > (name "grub") > (version "2.02-beta2-502-gc93d3e6")
Sure, that’s even better, and it works with ‘version>?’. (I would remove ‘beta2’ in this example, though.) The solution I suggested can still be used for repos that have zero tags, where ‘git describe’ doesn’t work (yes, it exists!). Ludo’.