I am talking about API in a more general sense instead of the more restricted sense of calling a module's functions/methods or variables. In the Log::ger case, a plugin returns a hash of hooks with names that are agreed upon. This is not enforced "mechanically", which can be a bad design choice in itself but I am choosing minimalism over stricture.

Anyway, making the plugin depends explicitly to Log::ger does not solve my problem. If Log::ger changes in a backward-incompatible way, I *will* break installed plugins unless clients choose to update the plugins (the dependants).

Why not just introduce some code in your distribution that can catch the plugins doing things the old, broken way, and gracefully throw a notice to the user and exit, with the notice advising them to upgrade the broken plugin (caller() could potentially be used to get the plugin name)?

Not ideal, but significantly better than forcing an upgrade of user installed distributions.

Yes, I did this to some extent, but there are still some scenarios where things could break. Your post reminds me that in other frameworks that I wrote, I do introduce API/metadata versioning and throw an exception whenever a plugin follows an older version which I no longer want to support. I might apply that to Log::ger too, thanks.

Thanks for the clarification, tho that's a bit over my head.

Hope Syphilis approach helps. :)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

You're welcome. And thanks for the response nevertheless. It tells me that I haven't expressed myself well enough :-)