Or if we back port any of those changes I’ll propose, then perhaps we can continue with the API at 2.x. That does require that the API target Java 8, though.
> On Jan 17, 2024, at 11:32 AM, 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. >
