Hi, I have the feeling you're talking at cross purposes here.
On Wed, Mar 18, 2009 at 12:14:27AM +0100, Markus Hoenicka wrote: > 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. What Andreas is discussing is, as far as I see, the versioning schema used by the GNU linker. Markus is talking about the libtool versioning system. Unfortunately, that's not the same thing. libtool is used to create shared libraries on a variety of systems. And not all systems use the same versioning schema of the GNU linker. So instead of specifying the ABI version directly, you give something that looks similar to a version number to libtool from which it will create a version as understood by the runtime system. I've been given to understand that the major version under GNU/Linux is calculated as major = current - age while other systems (iIrc FreeBSD) would use major = 1 + current - age. So, if you only add new functions, `current' and `age' are increased which will leave `major' at the same value. The `minor' number is, I think, basically equal to the `age' and the `patch' number is equal to the `revision'. For example, the libtool version 8:3:8 would result in the ABI version 0.8.3. Currently, 1:0:1 is configured (== 0.1.0). To denote a backwards incompatible change, you'd use 2:0:0 which would be translated to 2.0.0. > > > 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. This should be the same thing. > > 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. AfaIk that's correct. If you increase both, `current' and `age', the `major' version stays the same and the `minor' version gets increased. Again: The same thing. > > > 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. In fact, using the `current' number will yield higher versions much faster than one would manually set the `major' number. As you can see in the example above, the next major version (after `0') will be `2', because a backwards compatible feature has been added and `current' is increased regardless of any backwards compatibility. > 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. That's right, but.. I for one don't like the libtool schema at all. It's bad enough the developer(s) of a library need to know about it. Using this schema as the package version is very confusing: It isn't the ABI version (=> it's not useful for binary package maintainers), it isn't the API version (=> it's not useful for developers), it's just some piece of information required by libtool to generate an ABI version. So you, as the one executing `make dist', are the only one who ever *needs* to get in touch with these numbers. For everybody else, the libtool version are the ``arbitrary numbers''. It'll work, in the sense of ``people will find a way to calculate what they really need from these numbers'', but is that really necessary? Just to prove a point? Regards, -octo -- Florian octo Forster Hacker in training GnuPG: 0x91523C3D http://verplant.org/
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ 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
