Hi Robert,

Yes, sure that you have to dig into this issue for a while for came up with a good solution, this is not a trivial problem. Moreover, Quicklisp way to distribute systems would be another difficulty, right? Quicklisp does not deal with versions; the systems are packed in distributions.

Best,



On Wed, Mar 16, 2016 at 9:06 PM, Robert Goldman <rpgoldman@sift.net> wrote:
On 3/16/16 Mar 16 -6:52 PM, Alexandre Rademaker wrote:
>
> https://common-lisp.net/project/asdf/asdf.html#Version-specifiers
>
> So I can say that my system depends on a (:version :OTHER "x.y.z") which
> means a version >= x.y.z. Can I say explicit enforce a dependency of a
> particular version ? That is version equal of x.y.z instead of
> greater-than-or-equal x.y.z?
>
> Best,
>
> Alexandre Rademaker
> http://arademaker.github.com/
>

No, I am afraid you cannot do that yet.  I have long wanted to add
version upper bounds.  This would be very useful for cases where one
knows that a library has changed its API, but you have not yet adapted
your system to the changed API.  [Think of all of those systems that
still must be compiled with old GCC, or that use Python 2, instead of 3,
etc.]

The semantics might require a little thought.  If we have
(:version<= :other "x"), is that satisfied by "x.1"?  I think probably
so -- we'd want this to be violated only by x+1, but of course
(:version<= :other "x.0") should be violated by "x.1".  This is in
spirit the same as the way the current version-satisfies works, but
arithmetically slightly different.

Similarly, do we want :version<= or do we want
(:version :other <lower> [<upper>])
perhaps
(:version<= :other "x.y")
should be syntactic sugar for
(:version :other "0" "x.y")

[If you publish a library with a version that's less than zero you
deserve whatever bad thing happens to you!]

I would be happy to accept a patch, but otherwise you'll have to wait
for me to get around to it.  Sadly, I'm badly blocked now, because I
don't have a dedicated ASDF machine, and my current ASDF test machine
for linux and windows is being chewed up running over a hundred hours of
experiments; I can't predict when I will be able to run the linux and
windows tests and release 3.1.7.  In the worst case not until mid to
late April.  This isn't ideal, but my company owns the machine, and the
work I do for them has to come first.

Best,
R