I am not sure agree. Companies that don't upgrade DBI releases are unlikely to upgrade DBD drivers more frequently; and they're always free to use older DBD releases. We don't want to hold developers hostage to the tendency of a few companies to be slow in upgrades.
At my workplace, a large corporation, we make multiple DBI and DBD::xxx releases available, and applications can choose their own versions. It'd be unfortunate if useful new DBI features would not be used by current DBD::xxx releases. That's not to say that incompatibility should be introduced just for fun. But if a DBD driver wants to use a new DBI feature, and that breaks compatibility with older DBI releases, the DBD driver author should go ahead. The Makefile.PL file for the DBD module will specify the minimal DBI release required. yair lenga wrote: > Hi, > > I would like to highlight the fact the in large corporations, bumping > DBI to new version is a major issue, as the module serve as a > foundation for hundreds of applications, which must be retested on every > change. As a result, large companies will bump DBI version every few > years. > > Also, large companies usually prefer to use vendor provided software. > Red Hat 4 is bundled with DBI 1.40, and Red Hat 5 is bundled with 1.52. > While this may not be the latest and greatest, this is the reality for > many development projects. > > My 2 cents - If possible, DBD drivers should be compatible with older > version as long as practically possible. This will make newer SQLite > versions viable option for most projects. > > Yair > > >> >> -----Original Message----- >> From: Darren Duncan [mailto:dar...@darrenduncan.net] >> Sent: Wednesday, January 14, 2009 9:19 PM >> To: General Discussion of SQLite Database; DBI Dev >> Subject: Re: [sqlite] request to become co-maintainer of DBD::SQLite >> >> These are replies to posts on the sqlite-users list. However, if there >> is going to be ongoing discussion I prefer it happen on the dbi-dev >> list. Not that sqlite-users isn't very on topic itself, dbi-dev just >> seems *more* on topic, I think. >> >> Clark Christensen wrote: >>>> One of my first code changes will be to require DBI 1.607+ >>> The current DBD-SQLite works fine under older versions of DBI. So >> unless there's a compelling reason to do it, I would prefer you not make >> what seems like an arbitrary requirement. >> >> I have 2 answers to that: >> >> 1. Sure, I can avoid changing the enforced dependency requirements for >> now, leaving them as Matt left them. However, I will officially >> deprecate support for the older versions and won't test on them. If >> something works with the newer dependencies but not the older ones, it >> will be up to those using or supporting the older dependencies to supply >> fixes. >> >> 2. On one hand I could say, why not update your DBI when you're >> updating DBD::SQLite, since even the DBI added lots of fixes one should >> have. On the other hand, I can understand the reality that you may have >> other legacy modules like drivers for other old databases that might >> break with a DBI update. I say might, since on the other hand they >> might not break. Still, I'll just go the deprecation angle for now. >> >>> Otherwise, it sounds like a good start. Matt must be really busy with >> other work. >>> I'll be happy to contribute where I can, but no C-fu here, either :-( >> Thank you. >> >> Ribeiro, Glauber wrote: >> > My only suggestion at the moment, please use the amalgamation instead >> of > individual files. This makes it much easier to upgrade when SQLite >>> releases a new version. >> Okay. >> >> Jim Dodgen wrote: >> > I'm for the amalgamation too. the rest of you ideas are great also. >> > excelent idea to use Audrey Tangs nameing convention. >> > >> > I have been stuck back at 3.4 for various issues. >> > >> > I do Perl and C and offer some help. >> >> Okay and thank you. >> >> -- Darren Duncan >> >> >> > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
