in reply to Sane deprecation policy for a CPAN module?
G'day Dallaylaen,
[Note: It is unclear from your post whether the deprecation warnings are from your own or third-party CPAN module(s). If the former, some of what follows may not be pertinent.]
You wrote about "... backward compatibility ..."; however, you also need to consider forward compatibility.
If you search perldiag, you'll find entries containing text like:
"... is deprecated, and will disappear in Perl 5.xx ... (D deprecated) ..."
"Deprecated ... This will be a fatal error in Perl 5.xx ... (D deprecated) ..."
"... (F) ... was deprecated in Perl 5.xx, and became fatal in Perl 5.yy."
When you use modules, you can specify a minimum version for those modules. You can also specify a minimum Perl version with use. Also see the no function.
The if pragma can be used to conditionally load modules based on the current Perl version. (Its conditions are not limited to this type of check.)
In your Makefile.PL, you can specify a minimum version for both Perl and dependent modules: see ExtUtils::MakeMaker. Module::Build offers similar facilities.
Provide clear documentation. Obviously, this will depend on how you end up handling this. You might provide a final end-of-life version of X::Y::Old with doco recommending changing to X::Y::New. You might update the current module with doco explaining why this version is preferred. Use POD and the README, INSTALL and Changes files as appropriate. I'd recommend using cross-references (e.g. "See the INSTALL file for details.") rather than copy/pasting tracts of doco from one place to another (which will almost invariably end up getting out of sync).
— Ken
|
---|