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>
>>>>> 
>>>> 
>> 


Reply via email to