Re: Best way to retire old code for unsupported database versions
"Martin J. Evans" <[email protected]>
| Newsgroups | gmane.comp.lang.perl.modules.dbi.sybase.devel |
|---|---|
| Message-ID | <[email protected]> |
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