*Abstract:* There will not be a Log4j 3 API. Both Log4j 2 and Log4j 3 will implement the Log4j 2 API.
In the video call we had with Ralph, Matt, Piotr, Christian, Robert, and I on 2024-01-19 (last Friday), we decided to proceed with this plan. In a nutshell, 1. We will *make the business logic of Log4j 2 API pluggable* in a way seamless to existing Log4j 2 users. Hence, everything that used to work for Log4j 2 API, will work intact. 2. We will use this (new) pluggability to *support Log4j 2 API in Log4j 3*. Hence, there will not be a Log4j 3 API. 3. Preferably, we will *move Log4j 2 API to a separate repository* with its own release lifecycle and further explore options on how to evolve it. Let me know if you have any questions or concerns. On Wed, Jan 17, 2024 at 5:11 PM 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? (We can move the contents of the `spi` package in `log4j-api-3.x` > to a separate `log4j-spi` module in `main`.) 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 > > I would appreciate it if you can help me to understand if I am > missing something. Otherwise, I would like to know why we need to make a > major release for a project that is identical to its previous version. >
