asdf version dependency

[Faré]

On Fri, Mar 18, 2016 at 9:58 AM, Robert Goldman <rpgoldman at sift.net> wrote:
> I think that your argument suffers from mixing together the concepts of
> "version control" and "versioned software."  Version control is indeed
> the concern of version control systems such as git and subversion.  But
> versioned software is not, as witness the use of version management in
> software installation systems such as RPM and apt.
>
I'm precisely distinguishing the two concepts, and trying to establish
a finer distinction between the roles involved in using them.

Note that ASDF version strings, that you here call "versioned software",
are really an API compatibility version, and thus maybe Dan Barlow was right
to model them after Linux .so numbers, even though the
"major number as compatibility breaker" didn't pan out in the end,
due to the model of Lisp software distribution as source differing
from the model of C software distribution as binaries.
So let's speak of software versions and version control
vs api versions and api constraints.

As a WRITER or one system B and USER of another system C,
you have control both software version and api version for B,
but you don't control software version for C and
can only loosely specify api constraints for C.

As a WRITER of C, you control both software version and api version for C,
but neither software version for B, nor api version for B.
[[[Although — maybe we could add a :breaks statement in the defsystem for C,
just like Debian does. This would allow you to warn users against using
known-broken combinations. Or this could be specified in a separate file
that comes with C. In any case, you should only be allowed to specify
known constraints about past releases, and that means putting the
incompatibility
constraint in C and not in B.]]]

As an INTEGRATOR of application A, you control all software versions
for all transitive dependencies of A on your system, including B and C.
Since this trumps control over api versions, you have no interest whatsoever
in adding constraints on api versions, because they would be redundant
underspecifications. You check the existing ones, but you don't need
gratuitously add your own. You otherwise try to be a USER of all dependencies
and if possible a WRITER of none, though you sometimes have to make
local patches
to B and/or C.

If as a USER or INTEGRATOR you have local patches to some dependencies,
and want to register the incompatibility because it is not going to be
resolved any time soon, then send a patch to C that declares the incompatibility
with old versions of B. But patching B to declare incompatibility with future
versions of C is always the wrong thing. See previous email about the right
things you may do.

> Indeed, if everything is managed in a single, or a set of interconnected
> VCSes, version control is less important, as you point out.  However,
> when one is not using VCS, e.g., when using quicklisp, or assembling
> software oneself from multiple locations, versioning (not version
> control) is important to efficiently assemble a coherent set of subsystems.
>
An integrator should always be having every version under control.
If he doesn't, it's his fault when things go south for him
and he can't build software anymore.
Quicklisp DOES use version control. Every distribution has a date
that specifies a coherent set of tarballs. When you update Quicklisp,
you update all the tarballs at once coherently, and that's the right thing.


> Even when using VCS it can be helpful.  I work with people who
> concurrently work on multiple different lisp-based projects.  Those
> projects use different mixes of libraries, and at times even different
> versions of the same library in different projects.  Sometimes,
> inadvertently, ASDF settings can bleed through from one project to
> another.  In such cases -- event when VCSes are pervasively used -- it
> can be quite helpful to have version metadata.
>
It's OK to have different mixes of libraries.
Check the diverging bits in separate file hierarchies and
export a different CL_SOURCE_REGISTRY.
To prevent accident, maintain hygiene and have different windows of
different colors.
If no top-level project is visible from the CL_SOURCE_REGISTRY of the
other projects,
you have a simple way to prevent building something in the wrong environment.
You'll want separate Emacs processes each with its own SLIME, anyway.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
It is proof of a base and low mind for one to wish to think with the masses or
majority, merely because the majority is the majority. Truth does not change
because it is, or is not, believed by a majority of the people.
— Giordano Bruno (1548-burned at the stake, 1600)