My thoughts were to do it this past weekend but I spent the whole weekend working on the documentation for Log4j Audit (please review). I plan to use the next several days to review what is in 2.11 and what other bugs I see that are very important that should be resolved there. I will also probably do my usual pre-release vetting over the next few days. Given that I’d like to get it done asap.
That said, I’d also like to get a release of Log4j Audit as well as Log4j Server. I expect Log4j Audit will take a bit longer to release though as I am sure there are things that still need to be improved. Log4j Server might take even longer as I don’t believe it has a site build at all. It probably doesn’t need much of one though. Ralph > On Feb 12, 2018, at 2:08 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > Hi All: > > Any thoughts on the timing for 2.11.0? > > Gary > > On Mon, Jan 29, 2018 at 3:00 PM, Remko Popma <remko.po...@gmail.com> wrote: > >> I will fix picocli before we get to that point. >> >> (Shameless plug) Every java main() method deserves http://picocli.info >> >>> On Jan 30, 2018, at 4:07, Gary Gregory <garydgreg...@gmail.com> wrote: >>> >>>> On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma <remko.po...@gmail.com> >> wrote: >>>> >>>> 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 >>> >>> >>> Speaking of Picoli: It imports java.sql, which it should not for core to >>> depend only on java.base. How should we deal with that? >>> >>> Gary >>> >>> >>>> >>>> >>>>> 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> >>>>> >>>> >>
