If we 1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes in `log4j-api-3.x` to a new `log4j-spi-3.x` module, and 2. Only implement `log4j-api-2.x` *interfaces* (not abstract classes!) in `log4j-core`
we can have a Log4j 3 without a `log4j-api-3.x` module, right? > We would need to compare the two branches of log4j-api > and see what the differences are. #2208 <https://github.com/apache/logging-log4j2/pull/2208> synchronizes `log4j-api` between `2.x` and `main`. Hence, I presume the answer to your question is "none", except the minor intentional differences shared in the PR description. > Doesn’t that mean users would now need log4j-api-2.x.jar > and log4j-spi-3,x,jar? No. `log4j-spi-3.x` will be used by `log4j-core`, `log4j-slf4j2-impl`, etc. Library authors who only code against the API or users who convert everything to SLF4J via `log4j-to-slf4j` will only need `log4j-api-2.x`. On Thu, Jan 18, 2024 at 6:13 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > Now that I have had 10 seconds to think about it. The change to the > property syntax and how PropertiesUtil works will create serious problems > for what you are proposing. > > Ralph > > > On Jan 17, 2024, at 10:02 PM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > The quick answer to this question is “I don’t know”. When we first > started on the 3.x adventure I can assure you that log4j-api was very > different in the 3.x branch because of the changes we needed to make for > JPMS and to the build. However, since we have since carried those changes > back to 2.x to a large degree it may be that you are correct and we don’t > need to create a 3.x version of the API. > > > > We would need to compare the two branches of log4j-api and see what the > differences are. > > > > Ralph > > > >> On Jan 17, 2024, at 9:11 AM, 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. > > > >
