[asdf-devel] In defense of ASDF & Semantic versioning

[Robert P. Goldman]

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