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.
dave
