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.
