in reply to Re^2: Upgrade-proofing overridden subroutines
in thread Upgrade-proofing overridden subroutines

If this is the case, your runtime overriding solution seems a bit fragile. In this case, if the original author/authors are unresponsive, the best you can do is to fork off from their work and use your forked modules in the code you deliver. You could pack the patched modules in your work, or give something to the community releasing the patched module (this is up to you and to your willness to cope with bug fixes in your forked module).

Yes, we all know what forking means, but you're probably thinking about forks in really active projects, where at a certain point different people would like to go in different directions. This does not seem the case of almost-dead modules IMHO.

If the original author(s?) come back to life, then, you can either decide to put your code back to their modules in your next release, or just stick to your already-working code. This probably depends on how much confidence you give to their rebirth, or how many bugs were solved in their patched version. But, again, you keep control over what you deliver, and don't get catched by accidental changes. Last, but not least, you don't get blamed if your Sub::Override doesn't work for that nasty corner case you didn't think of.

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.
  • Comment on Re^3: Upgrade-proofing overridden subroutines