You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2018/02/12 21:08:15 UTC
Re: Java 8
Hi All:
Any thoughts on the timing for 2.11.0?
Gary
On Mon, Jan 29, 2018 at 3:00 PM, Remko Popma <re...@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 <ga...@gmail.com> wrote:
> >
> >> On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma <re...@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 <re...@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 <bo...@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 <ga...@gmail.com>
> >> wrote:
> >>>>
> >>>>> On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory <
> >> garydgregory@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker <bo...@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 <ga...@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.goers@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 <bo...@gmail.com>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Matt Sicker <bo...@gmail.com>
> >>>
> >>
>
Re: Java 8
Posted by Ralph Goers <ra...@dslextreme.com>.
Setting up jobs like that in Jenkins is pretty easy to do.
Ralph
> On Feb 12, 2018, at 4:06 PM, Remko Popma <re...@gmail.com> wrote:
>
> For what it’s worth, I’m happy to review Log4j Audit as many times as desired. :-)
>
> For log4j-server (and future other components in separate repos): is it possible to set up a continuous build that compiles this component and runs the tests every time commits *to the main Log4j2 project* are pushed? That would help detect breaking changes, which is my key concern with moving stuff out to separate repos.
>
> This is not a precondition for the releases Ralph mentioned, but we should test this idea with log4j-server before proceeding with the modularization.
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
>> On Feb 13, 2018, at 6:46, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> 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 <ga...@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 <re...@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 <ga...@gmail.com> wrote:
>>>>>>
>>>>>> On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma <re...@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 <re...@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 <bo...@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 <ga...@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory <
>>>>>> garydgregory@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker <bo...@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 <ga...@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.goers@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 <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>
>>
>>
>
Re: Java 8
Posted by Remko Popma <re...@gmail.com>.
For what it’s worth, I’m happy to review Log4j Audit as many times as desired. :-)
For log4j-server (and future other components in separate repos): is it possible to set up a continuous build that compiles this component and runs the tests every time commits *to the main Log4j2 project* are pushed? That would help detect breaking changes, which is my key concern with moving stuff out to separate repos.
This is not a precondition for the releases Ralph mentioned, but we should test this idea with log4j-server before proceeding with the modularization.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Feb 13, 2018, at 6:46, Ralph Goers <ra...@dslextreme.com> wrote:
>
> 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 <ga...@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 <re...@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 <ga...@gmail.com> wrote:
>>>>>
>>>>> On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma <re...@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 <re...@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 <bo...@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 <ga...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory <
>>>>> garydgregory@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker <bo...@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 <ga...@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.goers@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 <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>
>>>
>
>
Re: Java 8
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@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 <re...@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 <ga...@gmail.com> wrote:
>>>
>>>> On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma <re...@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 <re...@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 <bo...@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 <ga...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory <
>>>> garydgregory@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker <bo...@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 <ga...@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.goers@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 <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>
>>