RE: Best way to retire old code for unsupported database versions

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: [email protected]
> To: [email protected]
> 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