[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