Keeping the version in filenames Göran Weinholt (01 Oct 2009 16:29 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 05:53 UTC)
Re: Keeping the version in filenames Göran Weinholt (02 Oct 2009 12:59 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 16:22 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 17:24 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 20:13 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 16:51 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 20:25 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 13:06 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 16:26 UTC)
Bye-bye versioning Derick Eddington (02 Oct 2009 19:56 UTC)

Re: Keeping the version in filenames Derick Eddington 02 Oct 2009 20:25 UTC

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
----------------------------------------------------------------