FAQ
Hi all,

I wanted to get opinions on how do deal with old code that clutters up the driver and is only needed for really old, outdated and unsupported versions of the database.

DBD::mysql has a lot of "#ifdef" clutter to deal with things that weren't supported in 4.0 and 4.1 (god forbid 3.x). 4.anything has long since not been supported by Oracle, Sky, Percona, etc. I don't know who might be running it, but I would love to rip out all the old code. The question then becomes: what to do about having something around that you can refer people who want to run 4.x (???!!!). Is a simple information tidbit "if you want to use xxx, you use version x.y.z version of DBD::mysql" ? What have others done about this issue?

Thank you for your opinions and advice on this matter!

Regards,

Patrick Galbraith

Search Discussions

  • Greg Sabino Mullane at Sep 27, 2013 at 2:53 am

    what to do about having something around that you can refer people who
    want to run 4.x (???!!!). Is a simple information tidbit "if you
    want to use xxx, you use version x.y.z version of DBD::mysql" ?
    What have others done about this issue?
    Yes, it is basically as simple as that. Some thoughts:

    * Make your abandonment of old versions in large chunks, don't simply
    phase out older versions over time. In other words, consolidate the
    pain into as few releases as possible. Ideally, one every 10 years. :)

    * Have a version or two with lots of warnings in the docs before
    making the change.

    * Make the change at a major version bump. Then you can tell people
    they need version x, rather than x.y.z

    * This is also a good time to break other things - such as requiring
    a newer version of DBI. Consolidate that pain!

    * Provide instructions in the docs about how to reach the old versions.
    Have the frozen version available somewhere other than CPAN too.

    * Expect people who have been living off of those #ifdefs for years to
    suddenly crawl out of the woodwork after you flip the switch and complain.
    Anticipate their complaints in your docs so you can simply point them there.

    (MySQL 4.x? I know places still running 3.x!)

    - --
    Greg Sabino Mullane greg@turnstep.com
    End Point Corporation http://www.endpoint.com/
    PGP Key: 0x14964AC8 201309262247
    http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
  • Darren Duncan at Sep 27, 2013 at 6:02 am

    On 2013.09.26 7:52 PM, Greg Sabino Mullane wrote:
    (MySQL 4.x? I know places still running 3.x!)
    Me too, such as shared web hosts that prize stability greatly, so if you got a
    server in 2000 and requested MySQL in 2001, you got 3.23, and then you were
    never given upgrades to it afterwards, except by having your whole account moved
    to a new server in 2013. -- Darren Duncan
  • Martin J. Evans at Sep 27, 2013 at 8:29 am

    On 27/09/13 03:52, Greg Sabino Mullane wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    what to do about having something around that you can refer people who
    want to run 4.x (???!!!). Is a simple information tidbit "if you
    want to use xxx, you use version x.y.z version of DBD::mysql" ?
    What have others done about this issue?
    Yes, it is basically as simple as that. Some thoughts:

    * Make your abandonment of old versions in large chunks, don't simply
    phase out older versions over time. In other words, consolidate the
    pain into as few releases as possible. Ideally, one every 10 years. :)

    * Have a version or two with lots of warnings in the docs before
    making the change.

    * Make the change at a major version bump. Then you can tell people
    they need version x, rather than x.y.z

    * This is also a good time to break other things - such as requiring
    a newer version of DBI. Consolidate that pain!

    * Provide instructions in the docs about how to reach the old versions.
    Have the frozen version available somewhere other than CPAN too.

    * Expect people who have been living off of those #ifdefs for years to
    suddenly crawl out of the woodwork after you flip the switch and complain.
    Anticipate their complaints in your docs so you can simply point them there.

    (MySQL 4.x? I know places still running 3.x!)
    Everything Greg said ++, plus:

    * when you make the break try and ensure your RT queue is clear of at least bugs or you'll get people saying they can't upgrade to get a bug fix because you withdrew support for their mysql version.

    * try and catch someone trying to build against old client libs and output a meaningful message rather than just have the compile fail - preferably do this in your Makefile.PL or Build script and with the correct exit status you'll get a NA on a smoker instead of a Fail.

    * as well as DBI, think about what Perl version you require - especially wrt unicode support although I see the latest DBI is 5.8.1 already.

    Martin
  • John Scoles at Sep 27, 2013 at 11:02 am
    Yep one of the more unplesnt parts of being a DBDer, Looking back I had to drop a few #ifdefs when I was the more active with DBD::Oracle.



    I just made up a chart on the POD



    http://search.cpan.org/~pythian/DBD-Oracle-1.66/lib/DBD/Oracle.pm#WHICH_VERSION_OF_DBD::ORACLE_IS_FOR_ME?



    I my case I sort of just followed what the Oracle policy was. Support two versions back only.



    However nobody has been updating the table:)



    Really have to find a week or two to get back an lay with DBD::Oracle



    Cheers

    John







    Date: Fri, 27 Sep 2013 09:28:51 +0100
    From: bohica@ntlworld.com
    To: dbi-dev@perl.org
    Subject: Re: Best way to retire old code for unsupported database versions
    On 27/09/13 03:52, Greg Sabino Mullane wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    what to do about having something around that you can refer people who
    want to run 4.x (???!!!). Is a simple information tidbit "if you
    want to use xxx, you use version x.y.z version of DBD::mysql" ?
    What have others done about this issue?
    Yes, it is basically as simple as that. Some thoughts:

    * Make your abandonment of old versions in large chunks, don't simply
    phase out older versions over time. In other words, consolidate the
    pain into as few releases as possible. Ideally, one every 10 years. :)

    * Have a version or two with lots of warnings in the docs before
    making the change.

    * Make the change at a major version bump. Then you can tell people
    they need version x, rather than x.y.z

    * This is also a good time to break other things - such as requiring
    a newer version of DBI. Consolidate that pain!

    * Provide instructions in the docs about how to reach the old versions.
    Have the frozen version available somewhere other than CPAN too.

    * Expect people who have been living off of those #ifdefs for years to
    suddenly crawl out of the woodwork after you flip the switch and complain.
    Anticipate their complaints in your docs so you can simply point them there.

    (MySQL 4.x? I know places still running 3.x!)
    Everything Greg said ++, plus:

    * when you make the break try and ensure your RT queue is clear of at least bugs or you'll get people saying they can't upgrade to get a bug fix because you withdrew support for their mysql version.

    * try and catch someone trying to build against old client libs and output a meaningful message rather than just have the compile fail - preferably do this in your Makefile.PL or Build script and with the correct exit status you'll get a NA on a smoker instead of a Fail.

    * as well as DBI, think about what Perl version you require - especially wrt unicode support although I see the latest DBI is 5.8.1 already.

    Martin

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbi-dev @
categoriesperl
postedSep 27, '13 at 2:23a
activeSep 27, '13 at 11:02a
posts5
users5
websitedbi.perl.org

People

Translate

site design / logo © 2019 Grokbase