Hi, I've uploaded prereleases of the upcoming libdbi and libdbi-drivers releases:
http://libdbi.sourceforge.net/downloads/libdbi-1.0-pre1.tar.gz http://libdbi.sourceforge.net/downloads/libdbi-drivers-1.0-pre1.tar.gz These prereleases serve the purpose of checking two major changes: 1) The "_r" or "recallable" interface As discussed previously, libdbi so far had problems to support projects which dlopen() modules which in turn are linked against libdbi. As the modules are usually designed to operate independently, both dbi_initialize() and dbi_shutdown() may be invoked more than once within the same process and wreak havoc on modules that expect their connections to be around as long as they run. The functions dbi_initialize(), dbi_shutdown(), dbi_set_verbosity(), dbi_driver_list(), and dbi_driver_open() now have equivalent implementations carrying the name suffix "_r". dbi_initialize_r() fills in a handle which the other functions use to access a particular libdbi "instance". A new function dbi_driver_get_instance() allows a connection to determine the instance. These changes were requested and largely implemented by Rainer Gerhards. 2) library versioning libdbi so far used arbitrary release numbers. libdbi-drivers release numbers were only half-arbitrary in that they were chosen to make it easy to guess which libdbi version they'd run with. Moreover, although libdbi is set up to use the libtool library versioning scheme, the version information has never been updated since the first release. This didn't haunt us so far, as the library is still backwards-compatible. However, it is just a matter of time until something breaks. Therefore I went ahead and set up configure.in to assemble the libdbi version string from the (now updated) libtool library version numbers. This eliminates one point of failure (no need to change *two* numbers) and results in reasonable version numbers. The next official release will be "1.0". If we add features that do not alter the interface, there will be "1.1", "1.2"... releases. If we alter the interface, a "2.0" release will follow. libdbi-drivers release numbers will match these, so "1.x" will again be compatible with any "1.y" libdbi release. Also, libtool takes care of tagging the shared objects appropriately (at least on unixish systems). After installing the prerelease, you'll find a libdbi.so.1 right next to your existing libdbi.so.0. This allows the loader to detect applications that were not linked against a compatible version of the library if we'll ever have to introduce changes which are not backwards-compatible. While the new interface and the new versioning scheme made it into the programmers manual, I didn't get round to add an UPGRADING file yet. In brief, upgrading isn't that hard at all. Although the older interface functions are labelled as "deprecated", they are still around. Therefore your applications should link against 1.0 with no changes whatsoever. To make use of the new interface, you'll have to change all occurrences of the old interface functions and replace them with calls to the new equivalents. It is mandatory *not* to mix old and new interface function calls! This is almost guaranteed to crash your app. If you start to migrate, stop no sooner as all "deprecated" messages in your "make" output are gone. If you want your application to support both 0.8.3 and 1.0 installations (packaged OSes are sometimes slow to pick up new versions), you can use wrapper functions in your program. See tests/test_dbi.c in libdbi-drivers for an example how this might look like. Now if you made it until here, please allow me to ask you to test the new releases on as many OSes as possible. Although the "1.0" label was chosen for different reasons (see above), unsuspecting users may infer some sort of stability or maturity. I'd hate to disappoint their prejudices, so please flood this list with feedback! regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
