4.2 looks good, if it it released before then (well, even if it's only alpha or beta is fine too though).

Making the bridge compatible with both versions can get interesting. For some handlers this might mean creating two versions of the class. Also, some handlers don't seem to have tests, unfortunately.

Would it be a good idea to deprecate Monolog-1-only functionality then and have Monolog 2 as a minimal requirement for Monolog Bridge in Symfony 5?

@derrabus AFAIK, there is no Monolog-1-only functionality. BC breaks are about requiring type hints in some handler APIs (and so forcing handlers to have them).

@nicolas-grekas based on my discussions with @Seldaek, a PHP 7.1+ codebase should be able support Monolog 1.x and 2.x with the same code (as PHP allows adding return types in child classes). If that's indeed true, I suggest doing this work in 4.2 (doing it in 3.4 would require shipping 2 implementations with a version check as the Monolog 2.x handler cannot work on PHP 7.0 or PHP 5.x due to the return types being used)

@stof 💯 PR welcome to start that work, maybe @derrabus you'd like to give it a try?

PHP allows adding return types in child classes

PHP allows to add return types in child classes, but it doesn't allow to remove them. So for instance, if we add a bool return type to the isHandling() method of our handlers, we would still be compatible with the interface of Monolog 1.x, but we would break any application code that extends one of our handlers and overrides the isHandling method. That's a BC break.

Then there are cases like SwiftMailerHandler. Here we override the send() method that now has a scalar type-hint on its first parameter. That's a problem:

• If the parent class does not have a parameter type-hint, we cannot add one: https://3v4l.org/HGqJS
• If the parent class has a parameter type-hint, we cannot remove it (as long as we need to support php 7.1): https://3v4l.org/Ked4d

In this case, we won't be able to create a version of the class that is compatible with Monolog 1.x and 2.x.

maybe @derrabus you'd like to give it a try

Sure!

I have submitted a first shot as #27905.

but we would break any application code that extends one of our handlers and overrides the isHandling method. That's a BC break.

for that case, it would be true forever. So it would force to deprecate existing handlers, replacing by similar ones using the typehints

Then there are cases like SwiftMailerHandler. Here we override the send() method that now has a scalar type-hint on its first parameter.

this one is indeed an issue. As this extended SwiftMailerHandler is about supporting the memory spool, which is part of SwiftMailer itself, not of Symfony, I suggest upstreaming it instead (the 2 event listener methods could be replaced by a method allowing to mutate $this->instantFlush, which could then be called by a Symfony listener)

So it would force to deprecate existing handlers, replacing by similar ones using the typehints

That would work, but I'm having trouble finding a proper naming for the replacements. For instance I would deprecate Symfony\Bridge\Monolog\Handler\ConsoleHandler and create a new one named…?

• Symfony\Bridge\Monolog\Handler\Monolog2ConsoleHandler ➡️ That's ugly.
• Symfony\Bridge\Monolog\Handler\TypeHintedConsoleHandler ➡️ Too technical.
• Symfony\Bridge\Monolog\Monolog2Handler\ConsoleHandler ➡️ Feels redundant.
• Symfony\Bridge\Monolog2\Handler\ConsoleHandler ➡️ That would mean creating a new package. After all, we don't want to deprecate the whole bridge, do we?

We could also think about applying the pattern that the PHPUnit bridge uses for this purpose, with a ConsoleHandlerForV1 and a ConsoleHandlerForV2 and ConsoleHandler would then alias one of them depending on the actual Monolog version. But that would make the code a lot less navigatable, I guess.

would then alias one of them depending on the actual Monolog version. But that would make the code a lot less navigatable, I guess.

and that would still be a BC break, as the ConsoleHandler would still be the one extended by child classes (and so could require having the typehint when Monolog 2 was used)

and that would still be a BC break

Only if the application itself upgrades from Monolog 1 to Monolog 2. But that's the point where a BC break would be expected.

IMO if creating a new interface is the only option it should probably be Symfony\Bridge\Monolog\Handler\MonologConsoleHandler.

In theory we could deprecate it again in 5.0 and move development back to ConsoleHandler

Only if the application itself upgrades from Monolog 1 to Monolog 2. But that's the point where a BC break would be expected.

But I'm quite sure most apps have a dependency on MonologBundle and no direct dependency on Monolog itself (we could argue that they should have it once they start writing their own handlers depending on the library extension point, but that is likely not always happening).

IMO if creating a new interface is the only option it should probably be Symfony\Bridge\Monolog\Handler\MonologConsoleHandler.

In theory we could deprecate it again in 5.0 and move development back to ConsoleHandler

We simply cannot keep BC for people extending our handlers if we want to start supporting Monolog 2 before Symfony 5.0. If we create a new class with the proper return types, code extending the existing class without the return types would still break if Monolog 2 gets installed (as our own code would be incompatible with it). The necessary plan to support such case would be:

• add checks in Symfony 4.2 triggering a deprecation notice if they extend the class without adding the return types (they can already do it, unless they themselves need to account for child classes, but then it forces them to do the same process than us earlier than us)
• in Symfony 5.0, add the return types on our own classes. At that point, we become compatible with Monolog 2.

It's been one year since this discussion stalled ... but Monolog 2 is almost here: a couple of days ago 2.0.0 beta2 was published: https://github.com/Seldaek/monolog/releases

Monolog 2 is targetting PHP 7.2 so Symfony 5 should be the target for moving to it, this probably simplifies things a little.

@javiereguiluz @Seldaek My PRs #27905 and symfony/monolog-bundle#300 are waiting for comments and reviews.