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
