Re: Version strings for VCS snapshots

[ludo@gnu.org (Ludovic Courtès)]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Eric Bavier <ericbavier@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’.