I am afraid I don’t really understand that. How does moving the spine content to another module help? Doesn’t that mean users would now need log4j-api-2.x.jar and log4j-spi-3,x,jar? What is the benefit of that?
Ralph > On Jan 17, 2024, at 12:09 PM, Matt Sicker <m...@musigma.org> wrote: > > That might work, yeah. > >> On Jan 17, 2024, at 12:46 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: >> >> We can move the spi package content in main to a separate module in main. >> SPI problem is solved? >> >> On Wed, 17 Jan 2024 at 18:33, Matt Sicker <m...@musigma.org> wrote: >> >>> I suspect this won’t work that well once I’ve implemented >>> https://github.com/apache/logging-log4j2/issues/1977 as the current >>> provider SPI is fairly lacking. It might make more sense to release the >>> main API as 3.0.0 and have 2.x depend on the updated API. >>> >>>> On Jan 17, 2024, at 10: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. >>> >>> >
