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

[Anton Vodonosov]

Semantic versioning makes one good thing - it concentrates
on difference between API compatible changes and API
incompatible changes.

This is an important concept and it remains valid
for binary components and for source code.

But semantic versioning is not a complete solution.
It allows to detect incompatibility problem, but
it doesn't say how to solve or avoid this problem.

I wouldn't want to see library authors advised:
"You can break API compatibility; in this case
just increase major number in the :version
attribute of your asfd:defystem, and the problem
is solved."

It does not solve the problem. For example,
I would not want to see a library like alexandria
to break compatibility by renaming half of it's
functions and reflecting this just by :version
attribute. Suppose postmodern adopted new alexandria,
but hunchentoot hasn't. As new and old alexandria
can not be used simultaneously, my application build with
hunchentoot and postmodern can not benefit
from improvements and fixes in the new postmodern
until hunchentoot is updated.

Releasing an incompatible library version
essentially splits lisp world into two sets:
libraries depending on new version and libraries
depending on old version. And these two sets
become incompatible and can not be used in the
same application.

Doing so would impose a significant friction to
the lisp wold evolution. Once you depend on a
library from one set, you are locked in this set.

If we put the incompatible version into new
package (alexandria2 or carthage, whatever)
and allow it to coexist with the old version,
we allow other libraries to evolve freely,
without constraining the development agility.

I hope it is clear by now, that the library
maintainer is not expected to provide support
for old versions. Just leaving the old versions
available for use results in sigificant benefits.

We can generalize it to other forms of :version specifiers
and :depends-on specifiers, be it list designators,
open ranges, etc. In general this may be described as
consumer speficies some contraints on the supplier
library consumer can work with, and the supplier
describes itself so that the library loader,
when loads an application dependencies, can solve a kind
of constraint satisfaction problem and chose
from the library verions available on the system
the versions which satisfy all the consumers
in the application.

People can experiment with various forms
of the supplier properties/contrains specifiers:
dot separated numbers, lists of features, etc.
But it's not enough to just describe the
constraints. We also need a guidelines or
strategy for developers to ensure it is possible
satisfy all the constraints. If my application dependency
tree contains two incompatible versions
of a library (some-lib 1.0.0 and some-lib 2.0.0
if we use semantic versioning), then it is impossible
to satisfy such requirments, unless these
two versions can be loaded simulaneously.

22.11.2013, 01:15, "Faré" <fahree at gmail.com>:

> When you compile, you can detect API discrepancy, etc. In the C world,
> you do that with autoconf, #ifdef, etc. A same piece of source code
> will happily compile against a wide range of versions of the C
> library, and usually doesn't check version numbers, only the
> availability of given functions and CPP macros. Most of my C programs
> can compile unmodified against linux libc4, libc5, libc6 and whichever
> BSD libc, etc.

No, consider when libc7 is released, and some functions
are removed or changed behaviour. It may break you
C programs, because your code can not be prepared for
arbitrary future changes. That's the question of
backward compatibility - how supplier components should
evolve to allow existing clients to remain functional.

I think it is not bad to make :version-satisfies customizable.
In this case I would also suggest make :version
not necessary a string, but allow some
other values, like list of tags, etc.

Robert, if we want to continue from the version
mismatch condition, the condition object
might list the alternatives available:
other versions of the required ASDF
systems which are found. And if no alternatives
available, we can't continue.

Best regards,
- Anton