[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: qthreads / guile-readline version suggestion
From: |
Thien-Thi Nguyen |
Subject: |
Re: qthreads / guile-readline version suggestion |
Date: |
Sat, 02 Mar 2002 17:03:45 -0800 |
From: Rob Browning <address@hidden>
Date: Fri, 01 Mar 2002 18:39:52 -0600
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.
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 :>
very good points. this uncertainty is annoying.
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.
ok, i'll write some simple programs to (more) objectively verify
compatibility and check them into a new cvs module -- this will be the
beginning of our "cross-release testing framework". this is better than
relying on ChangeLog entries or other heuristics, but unfortunately
takes longer...
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.
if you don't want to wait for verification and keep the conservative
numbers, that's understandable and i would support that decision. in
fact, i would urge you to do that but consider also an approach that is
both conservative and allows offline verification: leave a space in
CURRENT, but set AGE to be 1, anyway.
in this case, instead of 1.0.1, use 2.0.1. (you can use the original 10
or 15, instead of 2, of course. the main point is that AGE is set to
1.) if 0.0.0 is proven indeed to be compatible, we can release it as
1.0.1, which would "chain" the compatibility between 0 and 2 (assuming
the linker DTRT, which may be a stretch). if 0.0.0 is proven not to be
compatible, we never release 1.x.
if the linker is not so smart (to determined through testing) , we don't
release 1.x, and there are no problems.
thi