There was also the idea that if we introduce some form of a v3 API, it’ll be alongside the existing v2 API, not a breaking change.
> On Jan 21, 2024, at 1:32 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > *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. >>
