On Fri, Mar 18, 2016 at 9:58 AM, Robert Goldman rpgoldman@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)