Hi Herve, On Fri, 1 Sept 2023 at 09:10, Herve Boutemy <hbout...@apache.org> wrote: > > it's not "mono vs multi (Git) repo setup" but "monolithic vs > component-oriented release"
Thanks for putting the discussion back on track. I think we could look at what other logging frameworks do. Ceki's SLF4J/Logback has: * one monolithic release for SLF4J + bindings to generation 1 logging backends; this really bugs me, since some (most?) releases only update the obsolete bindings, * one monolithic release for Logback. On the other hand James' JBoss Logging/LogManager has a separate release for each component. If we decide to split `log4j-api` into its own repo (let's say for 3.x) and have a separate release cycle: * we can safely split the two implementations `log4j-to-jul` and `log4j-to-slf4j` into their own repos/lifecycle, * we can safely split all the bridges into their own repos/lifecycle; remark that `log4j-jpl` should probably have been in its own repo from the beginning, since it even has a different Java version requirement, * `log4j-1.2-api` and `log4j-web` are partially joined at the hip with `log4j-core`, although their main functionality is independent. * all the remaining modules depend on the **internal** API of `log4j-core`. They could stay in the current repo. The way I see it, if one of the modules that depend only on the `log4j-api` needs a fix to work with a newer API, we messed up something. The modules that stay with `log4j-core` would still have a coordinated lifecycle, but we probably still need a separate repo/Maven module to test that everything works together. E.g. I am not entirely sure that someone can use `log4j-cassandra` together with `log4j-flume-ng`: their dependencies have incompatible Guava requirements and I don't know if our modules don't use Guava transitively. Piotr
