Migration path for 2.0 for external handlers

[stof]

The methods implemented by handlers have changed signatures between 1.x and 2.x. This makes it impossible to write an handler supporting both 1.x and 2.x at the same time.

This means that external packages must choose between supporting 1.x or 2.x.
In practice, it means creating a new major version to support Monolog 2, then requiring them to support 2 versions of their package in parallel because of Monolog itself. And if they add new features, this leaves them 2 choices:

• adding them only for people using Monolog 2.x
• giving up on semantic versionning by adding new features in older versions

This gets even worse when the package main purpose is not about shipping a Monolog handler, as forking branches because of Monolog would have a much bigger impact. And there is at least one such package: Symfony.
Thus, it would mean that the community is split hardly between 1.x and 2.x: you cannot upgrade to 2.x until all your handlers support 2.x, but it means you need to give up of updates in handlers already migrated if they don't backport all their changes in their old Monolog 1.x branch.
And given that Monolog 2.x requires PHP 7, it means that Symfony 3 would be forced to stay on the Monolog 1.x side of the barrier, making it impossible to adopt Monolog 2 in any Symfony project.

We would need to find a migration path for handlers, allowing to write integrations between Monolog and other systems that support both 1.x and 2.x to avoid such drawbacks (there was a similar discussion about Twig 2.x which did not have such plan either initially, making support of Twig 2 in Symfony impossible at this time).

[stof]

Note that there is no migration path issue for consumers, as consuming code is written against PSR-3 anyway.

[stof]

Note that the more we encourage people to maintain handlers outside Monolog itself, the more this migration path is important.

[Seldaek]

Indeed it's not possible to write a handler that's compatible with both versions, but that doesn't have to be a necessity IMO. Most of the handlers are very simple/stable and rarely require change, so having two branches active if you really care to support Monolog 1.x longer doesn't sound that bad.

Note that regarding semver, nothing in semver says that once you release a 2.x you have to stop providing new features in the 1.x line. That's just a policy Symfony decided on.

For symfony integration more specifically, I'd be interested to see the issues integrating Monolog 2 into Symfony 3. Most of the integration is done through the bundle, which could well support Symfony3 still while requiring php7.1+ and monolog2+. The bridge classes might be an issue indeed, which makes me really wish this wasn't all in one big repo and instead in the bundle itself, but anyway.. We have to see what's possible there.

I don't think holding back the 2.0 interface changes here makes sense if it's just for symfony3 bridge compatibility. If you see a way to improve interop without holding back progress I am all ears, but otherwise I'd rather break hard and keep maintaining 1.x for a while longer.

[Seldaek]

Had a chat with @nicolas-grekas and he seems to agree that it's not that big a deal to have a duplicate handler for PHP7.1+ and PHP5.5+ in Symfony 3.4 and then Symfony 4 - https://3v4l.org/u1G16 proves that a handler can be implementing both interfaces for Monolog 1 and 2 as long as the file requires php7.1+ - so I think we are fine.

[stof]

OK, so anyone writing code for PHP 7.1+ can make code compatible with both Monolog 1 and Monolog 2 by always adding the return types. Then it is fine with me.

[Seldaek]

I think that works yes, as long as you extend AbstractProcessingHandler you have all the stuff to make it work in both versions. If you don't then you'll have problems but it's kinda harmless to extend it.