On the compatibility front, it would be useful to figure out which parts of core are expected to remain compatible. Different plugin types will likely have different expectations of compatibility. — Matt Sicker
> On May 3, 2022, at 10:11, Gary Gregory <garydgreg...@gmail.com> wrote: > > 5. Define the binary compatibility requirements. > > Gary > > On Tue, May 3, 2022, 09:38 Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > >> Hi everyone, >> >> This topic has been discussed several times, but the list of features that >> need to be in version 3.0 is still fuzzy to me. From what I gathered >> version 3.0 requires: >> >> 1. JPMS support with non-automatic modules. This seems to be done for >> `log4j-api`, `log4j-plugins` and partially for `log4j-core`. The remaining >> modules need to be converted and I think there are still some classes if >> `log4j-api`, `log4j-plugins` and `log4j-core` that we can move to private >> packages. For example all the implementations of `PropertySource` in >> `log4j-api` do not need to be exported. >> >> 2. A DI system, which is certainly ready. However there are still places in >> the code where it is not used. For example the managers are still directly >> instantiated by the appenders, as well as some `log4j-1.2-api` builders >> that require constructor parameters. >> >> 3. The properties enhancement ( >> https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement >> ) >> proposed by Ralph. Personally I would like a `log4j-api` jar common to >> multiple web applications to be able to correctly detect a per-webapp >> `log4j2.configurationFile` property. >> >> 4. We could profit from the major version change to move some things >> around: for example do we really need three different file appenders? I >> think that from a use perspective a single `FileAppender` with three >> different file managers would be more intuitive. >> >> Piotr >>