Re: Versioning scheme-only modules.

[Rob Browning]

Neil Jerram <address@hidden> writes:

> First off, I'd like to say thanks for looking at this problem.
> Although I have next to no experience to contribute on it, I do think
> it's important, and I appreciate your persistence.

Thanks.  It's also confusing.  I've confused myself any number of
times while trying to figure out something reasonable :>

> Sounds good, although it's a pity that `#:interface' clashes with the
> module system's different usage of the word `interface'.

OK, so how about we be more explicit and use interface-version?
That'll be less confusing and it's not like the extra characters are
going to hurt anyone.

> Right.  (I was about to say that the libtool convention doesn't cater
> for the scenario where the interface hasn't changed, but you happen to
> know that some behavioural aspect of revision 3 differs from revision
> 2.  But of course that would really be an interface change, if it was
> detectable at all.)

Yep.  That's one of the things that confuses me too every now and
then, until I remember just how deeply all of this depends on people
being careful about their versioning.  For example, your interface may
change in a backward-incompatible way, even if you don't do
*anything* other than change the version of some sub-module you depend
on.

As an example, imagine you write (my foo) and it depends on (your bar
#:interface-version 3).  Now imagine that (your bar) gets upgraded and
changes its semantics and you dutifully update (my foo) to handle that
and change to depend on (your bar #:interface-version 4).

Now, if (my foo) in any way exposes the backward-incompatibility in
(your bar), then you'll also have to change (my foo)'s version
information to indicate that (my foo) has changed in a backward
incompatible way, and this can be easy to miss.  For example, if (my
foo) is passing objects created by (your bar) to its clients, then a
change in (your bar)'s objects may mean that (my foo) is backward
incompatible with its previous versions.

> Definitely <path>/foo/bar.scm.1.4.2 IMO.  The others conflict with
> validly unversioned modules (foo bar.1.4.2) and (foo bar 1.4.2).

Fine with me, thought that means we'll need a lot more -*-scheme-*-'s
in the files.

> I think we should follow the shared libs; i.e. drive this from
> Makefile.am.
>
> Installed files will be partly self-describing, from the file names
> under which they're installed; I think this will be enough.

And in the build tree, you'll have the Makefile.am to refer to...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD