This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
On Fri, 2009-10-02 at 19:51 +0300, Abdulaziz Ghuloum wrote: > On Oct 2, 2009, at 3:57 PM, GÃran Weinholt wrote: > > I'm all in favor of library versions and version references. I use > > them > > myself, as a courtesy to those who want to use my libraries, and > > because > > I want to be able to change the meaning of exported bindings without > > causing people too much trouble. > > In Ikarus, versions are supported for the purpose of checking for > availability of a certain version, and failing fast if the specified > version does not meet the actual library version. I certainly am > not going to add a SAT solver for picking which library must be used > among a set of available libraries, A SAT solver for this problem does seem pretty hairy. The other option for dealing with the problem is something external like a command-line option for specifying the exact version to use; but this very much goes against the rationale for version constraints in library references, which is to be able to say what version to use at the same place you say what library to use. The realities of complexity are unfortunate, because, IMO, it really would be ideal, from the highest, most conceptual perspective, to have versioning, with generalized version constraints, located at the names of and references to versioned libraries, and only located there. > and I certainly don't like to > just pick the first specified one (which is random more or less) > which is what this SRFI currently says I should do. The intent of the current draft was not to say that. The intent was to leave it up to implementations, which I thought was in the spirit of the other aspects of Scheme which implementations are free to differ about because there's not consensus. > I would like to keep version dependencies, constraints, conflicts, > etc., outside of the implementation as much as possible. I think your point about the appropriate granularity of versioning, i.e. the appropriate place to push the issues to, is persuasive. We are going to need versioning management at the package level, and that level is basically the same as the level for versioned libraries. We can have different packages for different versioned libraries which are under the same library namespace, e.g. (acme ---), and then the versioning management of everything is integrated. It is assuming the existence of a package manager, but if a package manager is going to exist, it's going to have to deal with managing versioning, and so it's probably better to leverage it instead of duplicating effort and functionality by having Scheme systems have a separate and redundant versioning management system. -- : Derick ----------------------------------------------------------------