Using the same API jar for 3.x core is intriguing. I like the idea of a cleaned-up API jar (no custom Supplier) that can front 2.x and 3.x.
I'd love to hash this out in a call. Gary On Thu, Jan 18, 2024 at 12:02 AM 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. >
