Markus Hoenicka wrote: > Hi, > > Andreas Ericsson writes: > > If you add functions to the library, it will remain LINK compatible > > with applications compiled against older versions of the library (so > > the ABI-version must not be changed), but programmers who wish to utilize > > I don't understand libtool's interface definition this way: > > http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning > > Unless I'm dense, the ABI version, i.e. LIB_CURRENT does change if you > add functions to the library. However, if you do it in a way that > allows apps programmed against an older version of the interface to > still work properly, LIB_AGE gets bumped up accordingly. > > > No it's not. It depends on how rigid your various version > > numbers are. For example, a change from 0.8.3 to 1.0 means all bets > > are off. Every function in the library could have a new name, or a > > different call signature or whatever. If you bump it from 0.8.3 to > > 0.8.4, you mustn't alter existing parts of the library but can only > > fix bugs that modify existing parts in a link-compatible way. > > 0.8.3 to 0.9.0 means you can add new functions (introducing a new > > .so-version that older applications can link against, but apps built > > against that version of the library cannot necessarily be linked to > > older versions of the library). > > > > First of all, I suggest to move to 1.0 (=1:0:0) because our library > version information has been broken since 0.6 (in fact, the stuff has > been broken from the very beginning as the maintainers back then > arbitrarily started at 0:5:0 instead of 0:0:0). We eventually have to > get this straight, and the changes implemented in the upcoming > release, like instances, provide a good occasion to do so. This is > admittedly a bit unclean, but further building upon the incorrect > interface numbers is probably not going to do us any good. > > Now for your discussion of the version numbers. I see this as a pretty > arbitrary convention to use the second position to denote interface > changes (what is the first position good for?). If you replace 0.8.3 > with 8.3, 0.8.4 with 8.4, and 0.9.0 with 9.0 in your above discussion, > all your points still hold true, but the shorter numbers could easily > be derived from libtool's interface version numbers. >
No. Major version bumps is for when you re-design the library (or parts of it) entirely so that it no longer remains backwards compile-compatible. Package managers like to have those three distinctions, and it's otherwise unclear to many when they need to change their code for their apps to keep on working. > > > > What changes would justify increasing > > > LIBDBI_MAJOR without affecting LIBDBI_LIB_CURRENT? > > > > None. But you could go from 0.8.0 to 0.8.1 without bumping the .so- > > version if you make some simple bugfixes without adding new functionality > > in 0.8.1. > > > > Just as I could go from 8.0 to 8.1 (LIB_CURRENT doesn't change, > LIB_REVISION gets bumped) without affecting the .so number. > > > If by "new interface" you mean adding functionality without touching old > > stuff in the library, it's because old applications can still run with > > the new library if you only bump the API version. > > > > And they can do so if I bump both LIB_CURRENT and LIB_AGE, unless I'm > way off. > > > > Also, a library isn't something > > > that needs to be marketed via version numbers. We'll never jump from > > > 1.2 to 5.0 just because some competitor has 4.0. > > > > > > > It's not about that, and all about being able to add new functionality > > without forcing old applications to be rebuilt against the new API *if* > > you didn't change the old one. > > > > Sure. I just wanted to make my point that library version numbers > need not be arbitrary numbers. It doesn't hurt if they simply reflect > the ABI changes. > > > (why is LIBDBI_LIB_AGE bumped here?) > > > > bzzt! wrong. Now every app linked against an old library will have to be > > relinked against the new one. A major headache for package maintainers. > > > No, because we've bumped LIB_AGE. > Right. I should've read up on libtool. I guess (LIB_CURRENT - LIB_AGE) somehow determine the .so-version. Either way, this is beginning to drift off-topic. Me, as a programmer / package maintainer, I'd like the version number to tell me * what project-version my code is being compiled against. * when new functionality is introduced that new packages may depend upon. * when a version of the library can no longer be used for old apps to link against. * when a library upgrade will prevent my code from compiling against the library's headers (preferrably without having to go and read patches etc). Which of those wishes you decide to honor, and how, is up to you as the package maintainer ofcourse. Sorry for falling into the trap of talking details about a specific solution when what I really want is just the short list above, which can obviously be solved in many ways. I'm just inclined to like the A.B.C idiom as it's fairly widely used. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ libdbi-devel mailing list libdbi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-devel
