Mike Rylander <[EMAIL PROTECTED]> was heard to say:
> hmmm... The libtool interface version number is about compatibility, > where as the release number is about human-understandable "freshness". > These are orthogonal concepts, though the former does deserve > attention. It seems to me that the LIB_CURRENT and LIB_AGE should > just both be 0, since there is no previously versioned interface. > Then LIB_CURRENT just gets bumped when new functions are added, and > LIB_AGE gets bumped as old functions are changed, deprecated or > removed. Trying to make the version number match the interface number > seem both counter productive (a new interface version for each > release?) and against libtool best practices, no? ... I may be > misunderstanding the proposal, though. > Maybe *I* am all dense about the libtool versioning stuff, but I see it like this: LIB_AGE is for recording the backwards-compatibility and thus is not relevant for the version number. All we have to consider is LIB_CURRENT (the number of the interface) and LIB_REVISION (loosely, the number of released source code changes that did not alter the interface). libdbi version numbers were picked rather randomly at the beginning, but as we had the drivers in a separate project, we wanted to avoid having, say, libdbi-drivers 8.3 depend on libdbi 7.5. We therefore decided to have all 0.8.x releases of libdbi work with all 0.8.x releases of libdbi-drivers and so on. While this schema does not strictly prevent changes to the application vs. libdbi interface (it prevents changes to the libdbi vs. libdbi-drivers interface), it is unlikely to change one interface without changing the other. Therefore we currently have "0.8" as a rather randomly picked interface number and "1" as the revision number. If we follow your request to release the current CVS code (more on that below), libtool would require no change of LIB_CURRENT, but LIB_REVISION would need to be bumped up. This is just what happens if we name the new release 0.8.2 (the interface remains at "0.8", the revision moves to "2". What I suggested in the discussion of the feature request back then is to make a clean start with the version and interface numbers next time we need to change the interface. The interface number, and thus the major version, should be "1", and the revision (= minor version) should start at "0". This is equivalent to stating that we'll bump up the major version whenever the interface changes, and the minor version whenever we add features that do not require a change of the interface. If we agree on that, there is no reason not to use the libtool numbers as the version number (LIB_CURRENT.LIB_REVISION). It is one set of numbers less that need the attention of the developers. > That actually seems fairly trivial for all types except > DBI_TYPE_BINARY -- that might require base64 encoding or the like. > I'll look into doing this. > Much appreciated. I also don't see major obstacles, except that we may need a couple of configure tests for any non-standard conversion functions. > I've been using the Postgres driver against an 8.2 database in > testing, and that seems to work just fine. > That's good. I was more afraid that MySQL 5.0 may cause trouble. Has anyone experience with that? > On a related note, we should also consider adding the "link libdbi > into drivers" patch that's been floating around into CVS. Our project > requires that we do this, as it uses the > > Parent => dl_open(app-logic) => dl_open(libdbi) => dl_open(libdbi-driver) > > pattern. When libdbi goes to load the driver it can't due to missing > symbols that the driver requires in the loading binary. Linking > libdbi into the drivers fixes this, it's a one line change in the > Makefile, and it does not break the more traditional setup. In fact, > this would help with the above mentioned libdbi <-> driver interface > checks. > > Note that any apache module that attempts to use libdbi will also > suffer from this. > I recall this discussion, but I didn't have enough time to look into this. We'll have to test whether the traditional setup is not affected by this on any platform supported so far. I'm especially concerned about Cygwin and Mingw. To speed up things, do you have a link to that patch handy? > Having said all everything above, I'd personally prefer to see a new > version out right now with the current code. It is tested and stable, > and does exactly what I need (other than the driver-libdbi linking > issue, but that's separate). There seems to have been a descent > amount of code added since 0.8.1 was released, and now that this > codebase is in use in a large production project (it's been tested > stable, etc) my immediate concern is stamping the code as "good" and > being able to point others at a tarball to say "that is tested and > works." As it stands, I get funny looks (or worse, no second look at > all) when I say, "Grab libdbi from CVS. Yes, it's stable and safe, > it's just not wrapped up in a download yet." So ... I'm sure you can > understand my frustration ... > I can feel your pain :-( I'm personally inclined to follow your suggestion and use the current CVS version plus the "link libdbi into drivers" patch (if it does not break things) to release 0.8.2 in a matter of days. I'd suggest to put the other changes on the back burner for another month or two and take our time to do it right. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
