So the old monolith code used to prepend "[error]" in its own so you've added new methods and you have to change the consuming code so that it uses them instead. If you have to update consuming code anyway, why not make a breaking change in the interface instead and do it properly?
You didn't break it on paper, i.e. it's binary-compatible, but not semantically compatible, since you still have to update existing code to use the new API correctly.
The interface breaking implementation does not break consuming code.
What the default method brings is the ability for consuming code to use the new methods without the need to update the logging library, only the logging library contract. But this gets into layers of control and ownership.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So the old monolith code used to prepend "[error]" in its own so you've added new methods and you have to change the consuming code so that it uses them instead. If you have to update consuming code anyway, why not make a breaking change in the interface instead and do it properly?
Because you don't want to break the existing consuming, and most importantly the implementing code.
You didn't break it on paper, i.e. it's binary-compatible, but not semantically compatible, since you still have to update existing code to use the new API correctly.
I agree, that's misunderstandable on my end. The point is that you can use the new API. Using it doesn't break the old implementation
The interface breaking implementation does not break consuming code.
What the default method brings is the ability for consuming code to use the new methods without the need to update the logging library, only the logging library contract. But this gets into layers of control and ownership.