I'd imagine keeping DBD::SQLite for v2 and creating DBD::SQLite3 for v3 is the most straightforward approach.
Actually, I just thought of a counter-example that may work even better. I propose that the existing DBD::SQLite name keep going as it is now, embedding all of the newest SQLite releases, including 3.x and onward. To effectively deal with multiple versions, I propose releasing the current 2.x version in a module called DBD::SQLite2 (if done now, it would contain 2.8.15). If this approach is used, then programs that only need to deal with database files that they themselves create will not need to be updated at all; only programs that actually want to deal with both v2 files and v3 files will need updating, to open the old files with DBD::SQLite2.
An alternate solution would be for DBD::SQLite to embed both 2.x and 3.x in it, with some switch to DBI's connect() function determining which to use, if new 2.x files are to be created, or no API change if not (all new files are v3). However, I don't particularly recommend this for the standard version because it makes DBD::SQLite bloated, even if that may actually be the most user friendly.
-- Darren Duncan
