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. > > 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. regards, Markus -- Markus Hoenicka markus.hoeni...@cats.de (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ------------------------------------------------------------------------------ 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
