Pascal Costanza wrote:
Just to chime in in the middle: There is no known solution to the so-called "DLL hell" problem. Libraries interact badly because of their interactions, not because one or the other is "bad." Even with the best of intentions, a library author cannot predict what changes will break existing clients and what changes won't, because that author doesn't know about all possible interactions. When APIs change, telling clients that they are now incompatible may be a lie, because they may not depend on the specific change. (For example, is the addition of a keyword argument an incompatible change or not? It may, or it may not be...)
You are basically trying to solve the halting problem for a program where you don't know significant parts of the program. ;)
I get it, but this is a "the better is the enemy of the good" argument. I know we can't *solve* the DLL hell problem. But that is not a good reason not to solve part of it. [Heck, I'm an AI guy -- *all* my problems are at least intractable, and none are solvable in the general case!]
When an API changes, telling a client it is incompatible is not a lie, it's a conservative approximation to the truth.
After all, telling a client that everything is fine (which is what we do now), is equally a lie.
So the best we can do is give a clue. And, along the lines of Fare's design principle, if I am changing the API, I am the only one who knows this. So I can signal this by bumping the major version number, and the first time someone tries to load, cause an exception. Now we can check the exception, and if it's not important, we simply update the versioning information and proceed.
Another thing that we could do would be to make the version errors continuable. I thought this was something that people would like, but I haven't seen any reaction positive or negative to this suggestion.
If it *is* important, we may have saved the poor programmer a ton of effort, since s/he is unlikely to get an error message that says "the API has changed, have you checked with your library supplier?" After all, emitting such an error message is equally equivalent to solving the halting problem.
There is a field of research about component-oriented programming where this was a hot topic for quite some time, and nothing ever came out of it. The only practical working solution was that of Microsoft COM, where you need to change a GUID when APIs change, and since it's a black box model, that covers a lot of ground. Common Lisp libraries are definitely not black box, so even this solution will probably not work that well. (Changing the name of the library or the system definition, as Vsevolod suggests, would be similar.)
If you want to give control to developers, you could provide a way that depends-on specifications are list designators, with some form of declarative way of precisely specifying which versions are compatible and which aren't. (Then you could describe situations like, compatible with everything up to and including 0.9.x, and everything above 1.0.0, but excluding 1.0.0 - a situation that actually occurred when Closer to MOP was incompatible with SBCL 1.0.0 for a brief moment in history... ;)
That we can do, and it would be useful, but that doesn't address the same problem as semantic version. Your suggestion involves the CLIENT developer reading the mind of the LIBRARY developer. That doesn't meet the need for the library developer to communicate in a broadcast way to all the clients (whom, in general, s/he will not know). It *does* provide a valuable way for the client to adapt to the library change and record the information that the client developer has learned about the state of the library.
Best, R