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
Best way to retire old code for unsupported database versions
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
Re: Best way to retire old code for unsupported database versions
-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!) - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201309262247 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAlJE8t0ACgkQvJuQZxSWSsgCxACgxPsWn+WT1LvbtCFIBzdeKUnk QS8AoJjZIYPUPJHBi71ynghGWN+4qRRx =88jH -END PGP SIGNATURE-
