Re: [RESULT] Making Log4j 2 API "the Log4j API"
Hi Matt, On Mon, 22 Jan 2024 at 19:35, Matt Sicker wrote: > > 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. Yes, that idea has also a PoC: https://github.com/apache/logging-log4j2/pull/2215 However right now I prefer Volkan's idea since: 1. Log4j 3.x **must** come out soon. I think everyone is tired of discussions on 3.x. Let's publish it and move onto 4.x. 2. Since the lifecycle of Log4j API and Log4j Core will be independent, we can switch to Log4j API 3.x at some point in the future. I would prefer to discuss Log4j API 3.x, based on some statistical data on how other logging APIs are used (e.g. how many parameters do people use) and on expert and user opinions. Right now we risk to design a Log4j API that we will need to patch multiple times in the future. Piotr
Re: [RESULT] Making Log4j 2 API "the Log4j API"
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ı 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ı 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. >>
[RESULT] Making Log4j 2 API "the Log4j API"
*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ı 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. >
