On Mar 26, 2009, at 10:30 PM, Darren Duncan wrote:
Hello,
So, out of my un-paid projects, my promise to take over release
management of DBD::SQLite (from the still incommunicado previous
owner) has now come to the front of my queue (now that Set::Relation
0.9.0 is out), so I'm now starting to think about it in detail and
get to work over the next week or two.
In that vein, the first and only major design change I intend to
make right from the start is to stop bundling the SQLite library
with the DBI driver and so the driver will have that library as an
external dependency.
--1. Prefer a system-installed lib, but use the bundled lib if one
cannot be found on the system. Don't make this harder for people to use.
While one of the selling points of DBD::SQLite versus other DBI
drivers in the past was that it came with everything you need, with
the advent of a single file "amalgamation" library being provided
standard from sqlite.org, as well as the increasing availability of
the SQLite library as its own shared system library install, I
figure it isn't too difficult now for users to either obtain the
library separately or use the one that came with their system, or
the DBD::SQLite installer could automatically download it similar to
how some other projects download their dependencies (Rakudo Perl 6
can download Parrot for example); so I don't think the ease of use
of DBD::SQLite is diminished significantly by it no longer bundling
the SQLite library.
Don't download it; a lot of times modules are installed where there is
no access to the Net. And those libraries that download external
dependencies never work very well (see Math::Pari).
On the other side, there is a lot of benefit gained from not
bundling. For one thing the size of the distribution as well as the
source control is cut down significantly, since the DBI driver alone
is orders of magnitude smaller. For another thing, occasional needs
to update for compatibility aside, DBD::SQLite will always be up to
date with the newest SQLite library; users just update the library
and possibly recompile the DBD::SQLite they already have. And so
DBD::SQLite won't need to be updated as often; it would just need
updates to address incompatible changes to the SQLite library, or to
fix bugs in or update features specific to DBD::SQLite itself.
These are benefits to the developer of the module, not to the end
user. I don't find them compelling.
Another quasi-change is that DBD::SQLite will be designed to work
specifically with the amalgamation version of the source files only,
not the pre-amalgamated versions; I say quasi-change since Audrey
Tang already did the work to convert DBD::SQLite to work this way,
in the separate ::Amalgamation distro.
Don't know anything about this.
Compatibility-wise, my DBD::SQLite will endeavour to work with all
versions of SQLite 3.y.z, though note that only 3.4.0 for which the
amalgamation file was a distinct download on sqlite.org (and 3.3.14
or so was the first that amalgamation was a make target). Or more
specifically, I only plan to test with the latest SQLite source
library available at the time (3.6.11 currently), as well as
probably whatever version comes with Mac OS X Leopard. Supporting
older versions will happen as I get advocates or testers for them.
I also won't explicitly drop support for any Perl or DBI versions
that the current DBD::SQLite supports, but I only intend to test it
with the latest DBI and Perl 5.8.x+.
If you don't test it with other versions, how can you be sure that
they're supported? I deal with this with pgTAP, BTW; I have to keep 5
separate PostgreSQL installations around to make sure it works with
all of them. You could probably script it to test that it works with n
versions of SQLite. That would obviously be an improvement over the
current maintenance.
A minor change is I will start out with using 3-part versions and
have a dependency on version.pm 0.74, which is bundled with Perl
5.10.x and an easy install otherwise.
Why? I see no benefit to this, and just imposes yet another
inconvenience on users.
Now a specific question for you:
First assume the new DBD::SQLite can look in at least 3 places for a
SQLite library to use, which are: 1. An amalgamation file that the
user explicitly put in the distro directory (or that was similarly
slipstreamed into a copy of the distro maybe by some OS package
manager); 2. A SQLite system shared library that was installed
either as part of the OS or later by a user; 3. Go and automatically
fetch a copy of the latest amalgamation file from sqlite.org,
similarly to how Rakudo Perl 6 can go fetch a copy of its Parrot
dependency from the 'net.
Now assuming that, changeable config options aside, there is an
automatic default order that these alternate sources will be used by
a hands-free CPAN/CPANPLUS/etc install, I ask you what options
should be used and in what order? Now I think we probably can all
agree that if choice #1 is satisfied (the user explicitly put a file
to use in the distro dir or a packager did), then it is clear-cut to
try to use that or die trying. What is less clear cut is whether
the next automatic default action should be to use an already
installed SQLite shared library or whether to download the latest
from sqlite.org.
Already installed.
I'm thinking that between #2 and #3, that #3 (get the latest) should
always be the default choice, and that users have to explicitly
override, such as by setting an environment variable, or whatever
already happens with DBD::SQLite, to use the system one instead.
It's far more error prone, and sysadmins like to control what's on
their systems, not have CPAN modules download and compile and install
stuff behind their backs. If I've installed SQLite on my system, I
expect DBD::SQLite to use it, not to install another one (and possibly
override what I've already installed, which may have other apps
depending on it).
So in fact the real question then is whether I should stay with the
precedent existing with the current DBD::SQLite, which effectively
is download from sqlite.org by default, or whether I should change
this default.
It should be in this order:
1. Amalgamation file put in the directory
2. System installed SQLite
3. SQLite distributed with DBD::SQLite.
I think that the downloading business is a bad idea.
Any thoughts on that matter, or on anything else I raised?
Yes. :-)
And while I suppose this is technically a fork, I'll still be just
using the name DBD::SQLite so my versions are picked up
automatically by users of the previous.
Now as for version numbering, I decided already to not use 4-part
versions like eg 3.8.11.0, but rather just use 3.x.y_NNN format for
my releases, with the X and Y values following my own preferred
pattern of Y for feature changes and Z for bug fixes, but that since
prior releases are already production status, I'll also use the _N
suffix convention for my initial or experimental releases and just
release without _N when testers report no show-stoppers, similar to
how the likes of DBD::Pg or Moose etc are released now.
So I'm wondering what would be the least contrived looking numbering
scheme in light of starting with _N, eg; would 3.0.0_001 be the best
for dev release start and then either 3.1.0 or 3.0.1 (depending on
whether features change from the _N) be the first non-dev release,
or should I start the dev releases in perhaps a more contrived 2.y
or 1.y space?
What's wrong with the current version numbering scheme?
Now I recall that someone had previously proposed making the SQLite
library an external dependency when my initial proposal didn't. If
they or anyone else wants to speak up with specific advice or
patches etc I'd appreciate it.
Also my DBD::SQLite will be in a public Git repository, either on
utsl.gen.nz or github or both, so I can receive patches by pulling
from someone's fork. Its not up yet though.
Thank you in advance for any feedback.
You *really* need to get Matt to signoff on this, IMHO.
Best,
David
