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, Alexandre Rademaker http://arademaker.github.com/ http://researcher.ibm.com/person/br-alexrad On Wed, Mar 16, 2016 at 9:06 PM, Robert Goldman <rpgold...@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 > > >
