Can you please give more details about the envisioned benefits?
This is a BC break so it likely won't be accepted.

Well, the benefit is that you can combine behavior of various activation strategies when using composition.

What I have in mind is to provide (in a dedicated bundle) a new ActivationStrategy implementation to be able to change dynamicaly (through endpoint or cli command or whatever) the actionLevel of ErrorLevelActivationStrategy or ChannelLevelActivationStrategy, and keep compatibility with HttpCodeActivationStrategy.
The use case would be to enable debug log for a short term period to be able to understand what is going wrong on the application, then switch back to the original log level.

You've basically implemented the decorator pattern for activation strategies. I see the benefit of stacking/decorating strategies, but the current implementation might break code that relies on the current inheritance. What we could do:

• Keep the inheritance, but stop calling the parent methods. Since we override all methods anyway, that shouldn't be much of a problem. In Symfony 6, we can drop the parent class and switch to the interface. The downside is that we cannot trigger proper deprecations on this, can we?

• Create your decorators as new classes and deprecate the current strategy classes. For instance, we would just deprecate HttpCodeActivationStrategy and create a new class HttpCodeActivationStrategyDecorator that should be used instead.

I see the point. Let me work on your second proposal. Additionally it will be more convenient to handle in monolog-bundle during the deprecated period.

@derrabus @stof @nicolas-grekas Here is a new proposal regarding your feedback

Looks good to me.

I wonder if we should finalize the new decorator classes. We should rather encourage people to stack decorators than to extend ours.

Just rebased on master, anything else I can do ?

Instead of creating new classes, I would instead accept both constructor signatures (we've done that multiple times in the past). The main benefit is to avoid having new class names.

@pvgnd Do you still want to work on this PR? What do you think of my proposal?

Hello @fabpot, your proposal was my first attempt before comments from other contributors. Introducing new classes allows us to make them final, which will discourage to break the decorator pattern. This will also make easier the deprecated code cleaning.

If you prefer to keep old classes and manage 2 constructor signatures, I can rework the PR. Please let me know and I'll give some time to rework on this.

If the goal was to make these classes final, you can mark them as such via the @final annotation at first and we would make them final in 6.0.

OK @fabpot I will update the PR

@fabpot Can you have a look please and tell me if it's OK for you?

Thank you @pvgnd.