[asdf-devel] asdf-version

Robert Goldman rpgoldman at sift.info
Sun Mar 14 16:46:44 UTC 2010


On 3/13/10 Mar 13 -7:36 PM, Faré wrote:
> On 13 March 2010 16:56, Robert Goldman <rpgoldman at sift.info> wrote:
>> On 3/13/10 Mar 13 -1:12 PM, Faré wrote:
>>> We could adopt the same algorithm as dpkg or rpm uses for comparing version.
>>>
>>> I once implemented it in shell script. Could do it in Lisp...
>>
>> I confess to not really knowing this algorithm (I haven't built an RPM
>> in a long time), nor having any guess about whether or not it would
>> break previous :version dependencies.
>>
> See attached file (supposes ASCII, will fail on EBCDIC).
> Add:
> 
> (defun version<= (v1 v2)
>    (ecase (compare-rpm-versions v1 v2)
>       ((< =) t)
>       ((> nil) nil)))
> (defmethod version-satisfies ((v string) (vmin string))
>   (version<= vmin v))
> 
> Do you think we should use that?
> 
>> Anyone know how backward compatible this would be?
>>
> It's backwards compatible with the current version-satisfies indeed.

Are you sure?

I don't think so.

Current ASDF version-satisfies treats the first digit specially.

To match a version spec of the form x.y.z with a.b.c, a must be equal to
x, not >=.  then b.c must be >= y.z

At least that's how I read it.  Probably this is a job for a unit test....

Also, I guess I think it's a little weird that

(version-satisfies "1.2.3-edgar" "1.2.3-dev")

Any reason in particular to choose lexicographic order for non-numeric
strings instead of requiring a match?  Works for 1.2.3a, 1.2.3b, etc., I
suppose, but "dev" seems like a weird case (perhaps one simply to be
avoided).

Frankly, given that this can be odd, I'd be just as happy insisting on

integer ( . integer )*

as the syntax for version strings and raising an error if the strings
aren't of the right form.

Indeed, I think insisting on some form for the version strings (and
validating it to the limited extent possible) would be very helpful ---
some of the utility of :version is vitiated by having people put in
strings that don't fit the convention.

Best,
R





More information about the asdf-devel mailing list