Re: [sqlite] request to become co-maintainer of DBD::SQLite

[Hildo Biersma]

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