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: boh...@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
