Backwards compatibility for Amavis::Custom
Currently, amavis does not explicitly define what may or may not be done inside custom hooks in order maintain compatibility within a major release. The comments in Custom.pm and RELEASE_NOTES are vague at best.
In theory, we could change Amavis internals any way we want without declaring these changes as breaking changes, because there were no guarantees to begin with. In practice, any little change could be breaking, because nothing was explicitly forbidden when users wrote their Amavis::Custom
implementation.
This situation becomes apparent when we try to introduce new custom hooks: Will they clash with user-defined subroutines? A new namespace, e.g. Amavis::Custom::V1
, is one obvious solution to this particular problem, but when we do that, we should create incentive to switch to it.
Some of these incentives would be a deprecation notice for the old namespace as well as explicit information what is allowed in hooks of the new namespace in order to keep upgrade compatibility. To do the latter, we would have to declare some of Amavis internals as part of its public API and/or define new code that will be part of said API.
In the best case, the API will be enough for any current Amavis::Custom
use-case out there as well as any future use-cases. In a slightly worse, but still good case, we would have to extend the public API or introduce a V2
namespace.
But more importantly, we do not have an overview of all current use-cases which may serve as a good starting point for V1
and its API.