[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Versioning scheme-only modules.
From: |
Rob Browning |
Subject: |
Re: Versioning scheme-only modules. |
Date: |
Tue, 04 Dec 2001 17:47:27 -0600 |
User-agent: |
Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 |
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