Re: qthreads / guile-readline version suggestion

[Thien-Thi Nguyen]

   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