Hello! "Neil Jerram" <[EMAIL PROTECTED]> writes:
> But this isn't obvious to me. _If_ the libtool versioning system > works in practice, in the senses of > > - permitting linking when it ought to be permitted > > - failing linking when it ought to fail It partly fails for the second point. Examples: changing the number/type of arguments of a function, changing the layout of a public structure, changing the implementation of public macros, etc. It really requires special care to check whether a change is breaking ABI compatibility. > then it seems to me that a reasonable division of labour is for us > (upstream) to take care of API compatibility, and ensuring that the > libtool numbers are a correct description of ABI state, and for > distributions/users to take care of any consequences of mismatched > libtool numbers. I consider ABI compatibility as important, too, because people don't want to recompile everything every time a minor release is out. Like Andy said, we should guarantee it within a given series, e.g., 1.8.x. After all, the version number is just a label giving users a hint about the type of changes introduced in a version and level of compatibility provided. It's common for free software libraries to remain ABI-compatible within a major series (first and second digits unchanged), to change to the second digit when ABI breaks, and possibly the first digit when API breaks *or* important changes are introduced. >> This is very convenient for binary distributions like >> Debian, and for users in general. > > Are you sure about that? Yes. Even for the few Guile C libraries I develop myself, it's boring to recompile them when switching from 1.8 to 1.9 or one of the other branches. For a distribution, it means burning a lot of CPU power. >> I think enhancements like the lazy symbol binding in modules >> could have been in theory added in 1.8.x since it breaks neither the API >> nor the ABI. > > Agreed; and I think they still can be added in 1.8.x. Yes, but one con could be that it introduces changes that could be visible to users that access Guile's undocumented module-fiddling API. > Yes, but it's an addition. As far as I understand, it's completely > back-compatible, so I would be perfectly happy to feed this in to > 1.8.x at some point. >From a marketing viewpoint, the VM deserves a new version number. :-) In practice, it also requires users to adapt their build system to take advantage of it. > Of course, we should take care that we are 99% happy with the new APIs > before releasing them, as it wouldn't be good to make lots of changes > later. But that's no different from the first public release of > anything - in my view, it should work much better for us to come to > this determination feature-by-feature, than to say arbitrarily at some > point "everything in master" is now ready. I agree that a feature-by-feature approach would be more reasonable. My impression, gathered since the time when Kevin was still with us, was that the goal was zero-breakage within a stable series, such that 1.8.x+1 would always be more portable and reliable that 1.8.x. This approach rules out things like the lazy duplicate symbol resolution, and `libguile-i18n'. Surely we could find an "in-between". > Not necessarily, in my view. We have an extensive test suite, and I > think we can have some confidence in that. After sufficient testing, > I would see no problem with your proposed BDW-GC changes going into a > 1.8.x release. The BDW-GC change is ABI-incompatible, it introduces a new dependency, augments the API and potentially introduces subtle changes in behavior, so I would definitely change the version number for that. Again, that version number is just a hint for users. >> BTW, we need to consider releasing 1.8.6 one of these days! ;-) > > Yes. Do we have any particular more things to get into this? (I > don't think I have anything.) I'm interested in the scm_c_read issue I raised on the list, and Linas is interested in threading issues. The former seems more important to me (eh eh ;-)) because it introduces a regression. Then, I don't think we have to solve every single bug right now, it's already been too long since 1.8.5. Thanks, Ludo'.