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

[Robert P. Goldman]

Anton Vodonosov wrote:
> The manual says:
> "the :version, :author, description and other [defsystem] fields are not required but they provide documentation and information for people that want to use this system.
> It also says in the section about asdf:operate:
> "If a version argument is supplied, then operate also ensures that the system found satisfies it using the version-satisfies method."
> 
> From some other places in the manual we can even guess how version-satisfies work.
> 
> Still, I think it was too much to expect from closer-mop to encode
> API compatibility information in the version identifier.
> Note also, in 2009 ASDF didn't consider version "0.6" as satisfying
> requirement for "0.55":

Yes, that's because the version scheme in ASDF is not a sequence of
period-separated integers, but a sequence of period-separated strings.
That was in ASDF 1, and we didn't dare mess with it.  Pascal was very
kind about this oddity, and has tweaked his revision numbering to fit
ASDF's constraints.

> http://lists.common-lisp.net/pipermail/moptilities-devel/2009-December/date.html

When Faré wrote up the design rationale for ASDF, one of the principles
was that ASDF should ask the right person for the right information.

For example, the library should not dictate where files go -- that's the
job of the library's installer (user).  The library itself knows where
its components are *relative to the installation* -- that's information
the library implementor will have, which the installer will not have.

Similarly, if I am the library supplier, I am the one who knows when I
have changed the API incompatibly.  That is why major component version
changes were intended *not* to satisfy version requirements that have
different major components.  This is reasonable, because it provides a
channel of information from the library supplier, that can be checked
automatically, and if the downstream is still compatible, it should be a
relatively easy fix (but is it?  I don't know if there's a good way to
say "I'll accept version 0.55+ or 1.0+").

The only other option would be to have the library client provide both
upper and lower bounds on the version numbers that the client will
accept.  But, except for cases of *known* upgrade incompatibility, this
is information that the library client simply cannot have.

The rules here are simple and easy to understand: if you change the API
in an incompatible way, bump the major version number.

Yes, this rules out the false modestly of version numbers like 0.0.145,
which looks like an alpha, but in fact turns out to be the fifth full
release, but that's a sacrifice we can all live with! ;-)

As my own devil's advocate, the counter-argument is that the state of
the art in CL libraries is so poor that even getting a version number is
unusual.  But this seems to be a counsel of despair: it says that since
we have a bad state of affairs now, we are doomed to live with it forever.

I suppose I could take a little while and write up a candidate
"versioning systems with ASDF" node for the ASDF manual, and push it for
consideration by the community.

> 
> Also, as we speak about versioning, I have been trying to use semantic
> versioning as described at http://semver.org/ and I don't think it is
> a silver bullet - it doesn't solve all problems.

Isn't the subtitle of /The Mythical Man-Month/ "No Silver Bullet"?

Yes, this doesn't solve every problem, but it might give you a useful
warning if your upstream has changed under you....  Pascal's case is an
odd one, because the bump to 1.0 is, in some sense, a false positive.

OTOH, it's not really so bad to have to take a look at a library that
has seen no commits in three years.

Cheers,
r