asdf version dependency

Alexandre Rademaker arademaker at
Thu Mar 17 13:53:42 UTC 2016

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.


Alexandre Rademaker

On Wed, Mar 16, 2016 at 9:06 PM, Robert Goldman <rpgoldman at> wrote:

> On 3/16/16 Mar 16 -6:52 PM, Alexandre Rademaker wrote:
> >
> >
> >
> > 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
> >
> >
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the asdf-devel mailing list