Markus Hoenicka wrote: > > Quoting Florian Forster <o...@verplant.org>: > > >> By all means, introduce version testing macros/defines, such as: >> #define LIBDBI_MAJOR 0 >> #define LIBDBI_MINOR 8 >> #define LIBDBI_PATCH 3 > > I'm not going to do that, as discussed before on this list. In brief, > we forgot to update the libtool interface version info in the past. In > the worst case your suggestion will cause us to forget to uptate the > interface version *and* the library version :-( >
Ah, I see the problem now. You're doing this the wrong way around. The API version mustn't be dictated by the ABI version, but it's just fine to do it the other way around (openssl does that, fe). The reason is this; 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 those new functions can't do so because they'll have no way of knowing what API they're programming against. >> #define LIBDBI_VERSION ((1000000 * LIBDBI_MAJOR) \ >> + (1000 * LIBDBI_MINOR) \ >> + LIBDBI_PATCH) >> > > I'll be happy to do something along these lines, based on the version > numbers that we have. > >> But mis-using the ABI version numbers for this purpose is evil, Evil, >> EVIL! >> > > Not quite. The warning in the libtool manual about not forcing the > library version into the interface version is absolutely correct. 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). Note that you can get around this by explicitly versioning symbols of the same name but with different call signatures (glibc does this, and it's why programs compiled against 3.3.6 work just fine against 3.2.0 of the library, assuming they aren't using functions introduced after 3.2.0). > But > instead of abusing the library version as an interface version, I'd > like to use the interface version as the library version. That's what's entirely evil. > I've never > understood why a library needs a version number that is different from > the interface number. It doesn't, but you need to let the library version set the ABI version in that case, in the way I explained above. > 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. > Why would changes > that require a new interface be reflected by an increase of > LIBDBI_MINOR instead of LIBDBI_MAJOR? 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. > 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. > So, to sum it up: > > Next release, called "1.0": > LIBDBI_LIB_CURRENT 1 > LIBDBI_LIB_REVISION 0 > LIBDBI_LIB_AGE 1 > > If we fix some bugs in that release, we'll have "1.1": > > LIBDBI_LIB_CURRENT 1 > LIBDBI_LIB_REVISION 1 > LIBDBI_LIB_AGE 1 > > If we add further functions in a backwards compatible way, we'll have "2.0": > > LIBDBI_LIB_CURRENT 2 > LIBDBI_LIB_REVISION 0 > LIBDBI_LIB_AGE 2 > (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. If you *CHANGE* parts of the API, it will be 2.0 because old apps will break down horribly if you try to run them using the changed API (with random stack frame corruption; Those issues can drive you mad and want to shoot the poor library developers who didn't realize why changing unsigned long to socklen_t in an exposed function in the library sucks tremenduously for 64-bit users). This is the reason most libraries have 3 version numbers. A.B.C: A is bumped when the library is re-designed so that no old application works without at least being relinked. B is bumped when new functionality is added. C is bumped when innocuous bugfixes that do not in any way what so ever alter how the ABI works are done. A and B usually make up the .so-version (openssl are a bit freakish as they use 0.A.BX, where X is always a letter, but they're the only major library to not use the 3-number scheme that I know of). Note that the programmer needs to know about the version of C in the compiled library as well, since he/she may well have to work around known bugs manually in case his/her program happens to run on a library of the old version while being compiled against a newer one. This is why most libraries have "libfoo_version()" return an unsigned long formatted the same way as the LIBFOO_VERSION macro. > All of this accessible to the compiler via: > > #define LIBDBI_VERSION ((1000 * LIBDBI_LIB_CURRENT) \ > + LIBDBI_LIB_REVISION) > > And, all updates to these numbers done in one place in configure.in. > > Would that cause any grief? > Possibly not, but possibly extraordinary amounts of it. I'm sure you can see why now. -- 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
