The log4j-api module could benefit from a util.internal package where we move the util classes that are private and should not be exported. Potentially an idea for a 3.0 release.
(Shameless plug) Every java main() method deserves http://picocli.info > On Jan 30, 2018, at 2:41, Remko Popma <remko.po...@gmail.com> wrote: > > If we want to do a 2.11 release that is binary compatible, I believe that > commit 21bc3aa is the last commit to include. > From the following commit (ba658a0) we start to move classes and rename > packages - this would better fit in a 3.0 release where users would expect > some breaking changes in core. > >> On Tue, Jan 30, 2018 at 2:37 AM, Matt Sicker <boa...@gmail.com> wrote: >> An SPI for log4j-core is one thing (also plugin factory cleanup). I'd like >> to see an improved plugin cache file that doesn't require a special plugin >> to merge them together when shading jars (would be better to just be cat'd >> together like a META-INF/services/ file). Removal of deprecated APIs would >> also be great. >> >> A 3.0 release also provides the ability to break APIs entirely if there are >> any awkward design decisions we found while incorporating GC-free logging >> and other nifty performance improvements. Utilising Java 8, we also have >> the ability to support fully non-blocking asynchronous APIs using >> CompleteableFuture which is rather interesting to me as well (particularly >> for networked appenders that provide async or reactive clients). >> >> As for bumping the version to 3.0 based on modules we already have, I >> thought the main version was tied specifically to log4j-api. >> >> On 29 January 2018 at 11:28, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> > On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory <garydgreg...@gmail.com> >> > wrote: >> > >> > > On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker <boa...@gmail.com> wrote: >> > > >> > >> I'd be +1 for Java 8, but making a 3.0 release is a different story. For >> > >> that, I'd like to see a lot more than just the Java version increase. >> > >> >> > > >> > > I think that a 3.0 would mark: >> > > - A major change: Java 7 to Java 8 >> > > - The internal clean up (in progress) with all the new modules >> > > - Others stuff like maybe an SPI. >> > > >> > >> > I would be happy to see an SPI for a 3.1.0 so we can take more time with >> > it. >> > >> > Gary >> > >> > >> > > >> > > Pushed back to 4.0 would be: >> > > - Remove deprecated classes and methods >> > > - Other stuff? >> > > >> > > Gary >> > > >> > > >> > >> On 29 January 2018 at 11:07, Gary Gregory <garydgreg...@gmail.com> >> > wrote: >> > >> >> > >> > +1 to Java 8 now and call the next release 3.0. >> > >> > >> > >> > Gary >> > >> > >> > >> > On Mon, Jan 29, 2018 at 10:03 AM, Ralph Goers < >> > >> ralph.go...@dslextreme.com> >> > >> > wrote: >> > >> > >> > >> > > Ceki has started a poll to upgrade Logback to Java 8 - >> > >> > > https://doodle.com/poll/s7n3wk59694pmnbs <https://doodle.com/poll/ >> > >> > > s7n3wk59694pmnbs>. The last poll I saw was in May of last year that >> > >> had >> > >> > > Java 7 at about 30%. https://plumbr.io/blog/java/ >> > >> > > java-version-and-vendor-data-analyzed-2017-edition < >> > >> > > https://plumbr.io/blog/java/java-version-and-vendor-data- >> > >> > > analyzed-2017-edition>. Based on the Java 6 graph I anticipate that >> > >> Java >> > >> > > 7 will be under 20% this year. I had been thinking that upgrading to >> > >> > Java 8 >> > >> > > in September or so would be the right time, but with all this >> > >> > > modularization work I am wondering if moving to Java 8 now makes >> > more >> > >> > sense. >> > >> > > >> > >> > > Thoughts? >> > >> > > >> > >> > > Ralph >> > >> > >> > >> >> > >> >> > >> >> > >> -- >> > >> Matt Sicker <boa...@gmail.com> >> > >> >> > > >> > > >> > >> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >
