Hi Volkan, On Wed, 17 Jan 2024 at 17:12, Volkan Yazıcı <vol...@yazi.ci> wrote: > Given Ralph and Piotr are strongly opinionated about keeping > `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release > `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` > instead?
The main problem with breaking the compatibility of `log4j-api` is that: * a logging API is used by virtually every other library, * we are at the bottom of the food chain If we have breaking changes, an application that wants to migrate to Log4j 3.x API will have to wait for **all** its dependencies to migrate to Log4j 3.x API. For a library to migrate to Log4j 3.x API will mean they need to start a new minor release that will only be used by applications, when other libraries do the same. Nobody is going to do this for a glorified System.out.println library. Remark that Gary also does not advocate for breaking changes in `o.a.l.l`, but he proposes to create a new package. This is technically **not** a breaking change. I am also not a big fan of this solution because it gives users **no** incentive to migrate to Log4j 3.x API. They will just accumulate several Log4j APIs in their applications as they do with Commons Lang or HttpComponents. The morale is that we should **never** break `log4j-api`. There is some middle ground to these extreme solutions: * we can create a new `v3` package and let the v2 interfaces extend those from v3 (proof-of-concept in PR#2215), * we could make breaking changes and instruct users to add `log4j-api` to the "provided" scope. At runtime `log4j-core` will depend on an "enhanced" version of `log4j-api` (let's call it `log4j-api-legacy`) that will have **all** the methods we removed from `log4j-api` and hence will be backward compatible with v2. > This will make everything > crystal clear: > > - Log4j 3 is just a major improvement over the backend > - Log4j 3 still supports Log4j 2 API > - We can move the Log4j 2 API to a separate repository with its own > release life cycle (ala SLF4J) > - When time comes to make a new Log4j API where PMC agrees to make > breaking changes, we can call that one Log4j 3 API Sounds good to me. We can mark as deprecated in 2.x all the classes from `log4j-api` that we consider either part of the SPI or totally internal to the project. Piotr [1] https://github.com/apache/logging-log4j2/pull/2215
