On Fri 09 Jul 2004 06:02, Dean Arnold <[EMAIL PROTECTED]> wrote: > Darren Duncan wrote: > > At 12:33 AM +0200 7/9/04, H.Merijn Brand wrote: > > > > 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^/
That's probably because the core fixes not only core bugs, but also the Ext modules that depended on it so end-users won't notice. It's the *modules* that use features, not the users. 95% of the users is just using the base and extends with modules. If I would tell about all the new core features since 5.8.0, I guess only the p5p people would tell me that it's actually used. A small bug fix is not a reason for most people to upgrade. TMTOWTDI takes care of that. They are happy it's fixed, but have found another way to do it I had to upgrade to 5.8.4 because of a very nasty format bug. Wolfgang Laun fixed that, and the Dutch law forced us to change the (many) scripts to run into that problem. > > And they still have the older DBI versions to use in perpetuity, > > regardless. If they are not going to upgrade perl, I bet you they also won't upgrade DBI The main reason for upgrading DBI is the fact that Oracle forced them to upgrade to Oracle-x.y.z (maybe because the new hardware does not support (x-n).(y-m).(z-o)), and thusly needs DBD-Oracle-v.w, and that requires DBI-2.ab and that requires perl-5.8.7 It's not the perl core that forces people to upgrade. It's the module at the end of thge dependancy chain. The module they are faced with. The one that defines their API > I'd never argue against migrating sites to perl 5.8 And I never argued against having DBI-v2 be backward compatible with 5.6 (or whatever version Tim or this community decides to). Backward compatibility is good, but there are also points of no return. I remember Monteray very well, and I think Tim was there too. That's where Perl-6 started: a point of no return. > (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) Since I'm probably the only active user of DBD-Unify (based upon the absence of feedback), I have absolutely no problem with raising the bar beyond DBI :) FWIW 95% of my production scripts use defined-or, and will not run on any machine that has vintage perl installed. -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
