guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qthreads / guile-readline version suggestion


From: Rob Browning
Subject: Re: qthreads / guile-readline version suggestion
Date: Fri, 01 Mar 2002 18:39:52 -0600
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i386-debian-linux-gnu)

Thien-Thi Nguyen <address@hidden> writes:

> presuming the qt/ChangeLog is complete, it seems to me libqt version for
> guile-1.6.x should be 1.0.1 (was 0.0.0 for guile-1.4), which reflects
> the nature of the changes since 1.4: only addition of interfaces / no
> removals.  (see rules 4 and 5 in the libtool info page.)

That sounds right, though we need to be careful of any publically
visible data structures, including any we might pass-through from
sub-libraries (in cases where that's relevant).  Also since we've been
a little sloppy in the past wrt shared lib versioning, I'm a little
concerned whether or not we can consider the ChangeLog a sufficient
authority...  Might be fine, though.

> a similar analysis also applies to libguile-readline version update (i
> think it should be 1.0.1 for guile-1.6.x, also).  the consequence of
> this fussiness (as opposed to simply using 15.0.0 or somesuch) is to
> allow users specifying CURRENT==1 to also be able to use CURRENT==0 if
> CURRENT==1 is not available.  a non-zero AGE is a Good Thing because it
> doesn't introduces gratuitous incompatibility.

Agreed, though I think we have to be *really* careful here because
although a gratuitous incompatibility would be inconvenient, an
inaccurate indication of compatibility could be much worse :>

> rob, what do you think?  we should write down some things in
> devel/policy/api.text -- the version table there is a first stab based
> on the various FOO-VERSION files, but i didn't do the archive diving to
> capture rationale yet.

We should definitely try and choose the "right" numbers for the
versioning when we can, and in this case, if it's actually correct,
I'd rather do what you're suggesting.  At the moment you seem to have
a good handle on the issues, so if you check things out and think it's
OK, then I'd be happy to defer to your judgement either way here.

By default, I was just being conservative because we hadn't been being
careful before, and I knew that bumping the interface and zeroing age
would be guaranteed safe.

(In the long run, every developer with CVS access will need to be
 aware of these issues when they're hacking on any of the library
 code.)

Thanks

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]