Re: Minor API changes in 10-year-old module

If you really want to be considerate of your users, you can release a new version that issues warnings every time your next version would behave differently.

warn "Next version of Module::Unknown will die instead of returning un
+def.\n";
return undef;
[download]

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Comment on Re: Minor API changes in 10-year-old module Select or Download Code

Replies are listed 'Best First'.
Re^2: Minor API changes in 10-year-old module by wanna_code_perl (Friar) on Sep 05, 2019 at 19:18 UTC
That's a good way to add a deprecation warning for this sort of situation, and a simple solution. Thanks! And I have no deadline for this, so it's no skin off my asterisk to release such a version now, wait six months or more, then release another. My only hesitation is that it'd also be nice to give users a way to "opt in" to the changes ahead of time, and I was originally thinking of doing that in the code itself, but I reckoned that could get ugly, multiply the unit test requirements, and add two more likely points to introduce regressions. But you've got me thinking. Maybe append your warning with "For new code, use development version USERNAME/Module-Unknown-2.00_01.tar.gz" or something to that effect, with a blurb in the docs on how to fetch a dev build. Or is there an even cleverer way? :-)	[reply]
Re^3: Minor API changes in 10-year-old module by holli (Abbot) on Sep 05, 2019 at 20:24 UTC
Well, you can. It's more work but you could make this first new version behave like the old version, with aformentioned warnings, but also support the fixed API when they use it with `use Module qw(:always-die);` or `use Module qw(:newapi);` or whatever. Then your next version can switch to new api and silently ignore that flag. holli You can lead your users to water, but alas, you cannot drown them.	[reply] [d/l] [select]
Re^4: Minor API changes in 10-year-old module by Tux (Canon) on Sep 06, 2019 at 10:28 UTC
If the new API is (clearly) better, I'd reverse that and add `use Some::Module qw( API2009 );` and have a few wrapper functions that are backward compatible. The docs can then say that this possibility will be removed in version x.yy or from 2020-09-10 forward. As a side note: there is absolutely no need for a `return` immediately following a `croak`. The `croak` will exit the current scope immediately causing the `return` to never execute. Code like that is misleading and wrong. Enjoy, Have FUN! H.Merijn	[reply] [d/l] [select]