Darren Duncan wrote:
At 12:33 AM +0200 7/9/04, H.Merijn Brand wrote:
You won't be leaving them behind. They still have DBI-1.xx
FWIW as per customer request, I am depending on 5.8.4 and up since two
weeks.
You can imagine that's a little bit earlier than I planned. And it's
not UTF-8
that makes me need 5.8.4
That's largely what I was getting at.
Besides Unicode, 5.8.x is a lot more thoroughly tested and bug free,
plus thread support is a lot more mature, plus there's PerlIO to work
with, plus various other advantages.
And, there is a different and/or newer set of modules included with it.
(Forgive my ignorance, but starting with which version of Perl was
Test::More bundled?)
The fact is, if not now, then before too long, 5.6.x will be the new
5.005 as far as the general developer community is concerned.
Alas, for much of the installing public, that won't be the case.
In my case, I've bitten the bullet and started a fork for my driver:
one that supports 5.6.x+, and another that requires 5.8.3+. Its a pain,
but getting some users to even consider moving to 5.6.x has proven
difficult, esp. in enterprise class environments, where the Prime
Directive is "If it ain't broke, don't fix it". Yes, I'm aware 5.005
might well be considered broken in places, but convincing a CIO
of that can be a challenge if your website has been happliy dishing
up webpages on 5.005 for several years. While I only provide
essential updates for the 5.6.x fork, there may be sites
that want DBI v2 features (whatever that ends up being),
but won't be willing to update Perl versions, at least not
to 5.8+ in the near future.
Hence, the test suite might be very valuable for pre-5.8
sites.
On the other hand, retrofitting DBI v2 features might be a profit center
for us DBD authors ;^), and a better impetus to the laggard users.
Perhaps as a middle ground, I can suggest that DBI v2 will support Perl
5.6 initially, but that support will be considered deprecated. This way,
5.6 people can move to DBI v2 to get some of the new features, but with
the fore-knowledge that they should upgrade to 5.8 before too long
afterwards.
That would be a "gentle forced migration" if you will.
If the core Perl developers can't crowbar users off 5.005,
I doubt us poor DBI developers have much chance of getting
them to move from 5.6 to 5.8, much less off 5.005.
Perhaps we're victims of our own success 8^/
And they still have the older DBI versions to use in perpetuity,
regardless.
One last thing: Have any surveys been done concerning what "for
production" versions of Perl are being used by what fraction of users,
both in general and those that also use DBI? For example, how many have
migrated to 5.8 already?
Solely based on the sites I support, I'd say few, at least for
production use.
> How many others are on 5.6?
Many more than 5.8, but not as many as you might think (or prefer).
> And how many others are on older versions of 5?
>
You'd probably be surprised/disheartened by the number still
running 5.005. I recently installed an enterprise class application
that still bundles ActiveState's 5.004 perl as part of their
install procedures.
Or, heavens forbid, 4.x or older?
Probably not too much of a concern; IIRC, Perl 5's release
pretty much coincided with the internet boom, so most people
hadn't even heard of Perl before 5.0 was released.
Where can I lookup such info, *other* than on Google?
Maybe perl.org or perlmonks ?
Point of reference: consider how many sites still run Oracle 7,
or Win NT4 ? A LOT! And Oracle and MSFT have armies of people
paid to push sites off those versions.
-- Darren Duncan
I'd never argue against migrating sites to perl 5.8
(in fact, I actively proselytize for that move), but
I think we need to be pragmatic and cautious about
forcing sites to migrate. DBI has become a mature tech
(thanks to Tim and the collective). We can choose to
dictate upgrades to the user community,
or take the "kinder, gentler" approach, albeit at
greater effort on our part. In the interest of greater
adoption, I'd suggest the latter.
IMO, I'd vote for 5.6 as an acceptable baseline for
the test suite. I won't suggest a baseline for
DBI v2, since its features and timeframe aren't yet
well defined, and may require DBD authors to
fork anyway. (Well, maybe not "require", since many DBD authors are
working gratis, so users will get only what the authors choose
to provide)
<Discretely drags soapbox offstage>
Dean Arnold
Presicient Corp.
