Front page | perl.dbi.dev |
Postings from January 2012
On 01/10/2012 09:30 PM, Yanick Champoux wrote: > On 12-01-10 09:47 PM, Darren Duncan wrote: >> >> After the first release of Oraperl in a separate distro, as long as you >> don't change something in DBD::Oracle that breaks the API that Oraperl >> depends on, you never have to release another version of Oraperl itself >> again. > > I thought about that option as well, but I don't think it buys us > anything. For as long as DBD::Oracle doesn't break Oraperl, to have the > latter bundled with the former doesn't require any additional work, and > doesn't hurt. And when DBD::Oracle will finally break Oraperl, having > Oraperl in its own distribution means that for it to work you'll have to > manually install a non-latest version of Oracle for it to work -- if > it's still bundled with DBD::Oracle, 'cpanm Oraperl' will do the right > thing and fetch the last version of DBD::Oracle that includes, and > supports Oraperl. > It seems that what it buys you is a sort of super-deprecation warning. If I use Oraperl, then the first time I update DBD::Oracle my code stops working, but I have a solution: Install Oraperl itself. But now I've taken this intentional step, and I "know" that my next update of DBD::Oracle will be at my own risk. The repackaging would keep Oraperl functional while making it something of a hassle to use, which seems a better motivation for people to stop using it than a deprecation warning. This spoken by someone who's still using DBD::Oracle v1.23 with almost never a complaint, so take my comments either with salt or as confirmation of Tim Bunce's observation that the intended audience rarely upgrades. daveThread Previous | Thread Next