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

[Stelian Ionescu]

On Wed, 2013-11-20 at 18:54 +0100, 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...)

Given the flexibility of CL, there are innocuous changes that might
break dependent code.
For example, adding a new return value to a function is
backwards-compatible if the latter is used via multiple-value-bind not
if the user employs multiple-value-list plus destructuring-bind. That's
perfectly legal CL and, in some cases, might be justifiable as the best
solution; even simply adding a function is not backwards-compatible if
the dependent code uses boundp at runtime.

> 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... ;)

The Haskell people tried that with cabal but their experience was that
too stringent dependency specs make upgrades a hell. Example:

FOO 1.5 depends on BAR <= 1.2 && >= 1.0
QUUX 0.7 depends on FOO <= 1.5 && >= 1.0 and BAR <= 1.2 && >= 1.0

FOO 1.6 is released with dependency on BAR <= 1.5 && >= 1.3

Now one cannot install QUUX any more because its dependencies cannot be
met. It directly depends on BAR <= 1.2 and indirectly on BAR >= 1.3
Users of QUUX will have to modify it locally and contact its developer
to update the definition of QUUX or fix it.

In practice it seems that the best thing to do is have relaxed
dependencies and rely on an integrator/distributor to put together
packages and developers have to make sure that when they make a release,
their library works with the most recent release of its dependencies. In
other words, work with snapshots of the development "world" and never
try to mix libraries from different ages.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20131121/58e561d9/attachment.sig>