On 2/14/07, Markus Hoenicka <[EMAIL PROTECTED]> wrote: > 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.
Sorry, I should have investigated much more closely before speaking... I was basing all that on the SF bug discussion, which was more about the abstract use of the LIB_* stuff, I believe -- or at least pre-use. If there's already a procedure in place then I don't want to suggest we change it. > > 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. > Sure, and for a library package that definitely makes sense. In fact the more I think about it the more sense it makes... :) [sinp] > > > 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? > It's actually the libdbi-drivers Makefile that needs patching, and it's currently specific to linux builds for us. Mingw and Cygwin may not mind dl-loading-a-dl like linux seems to. It's documented here: http://open-ils.org/dokuwiki/doku.php?id=libdbi and amounts to adding -ldbi to the LDFLAGS var for the drivers. > > 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, [snip] > > > > 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. > +1 Thanks, Markus! > regards, > Markus > > -- > Markus Hoenicka > [EMAIL PROTECTED] > (Spam-protected email: replace the quadrupeds with "mhoenicka") > http://www.mhoenicka.de > > -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org ------------------------------------------------------------------------- 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
