| Newsgroups |
gmane.lisp.cclan.general |
| Message-ID |
<[email protected]> |
>>>>> "Sean" == Sean Ross <[email protected]> writes:
Sean> [email protected] wrote:
>>>>>>> "SR" == Sean Ross <[email protected]> writes:
>>
SR> Hi all, I've been working on more comprehensive version
SR> support in asdf and i think it's finally ready for public
SR> consumption.
>>
>> [...snip...]
>>
>>
SR> This patch does not address the concept of compatible versions
SR> but I feel that that can be added at a later date.
>>
>> You lost me here. Can you expand on "compatible versions" (as
>> opposed to, presumably, "versions satisfying version number
>> predicate")?
Sean> aargh, poor choice of words. I'm thinking of a situation
Sean> where you have version 1.3.1 of system X loaded and you want
Sean> to load version 1.3.5 If these two version of system X are
Sean> "compatible" then it should be fine to load 1.3.5 instead of
Sean> signalling a continuable error.
What's the semantics of "load" in the above? Somehow load 1.3.5 in a
namespace where it will not collide with 1.3.1, or have the load of
1.3.5 crush 1.3.1?
Since CL does not have hard-core interface definitions (if you need
to, you can reach in and tinker with non-exported functions,
variables, etc.), I don't off-hand see how one could specify that
library versions are or are not compatible. Also, are there
transitivity issues? Is "compatible" a transitive relationship?
Best,
Robert
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV