Sounds reasonable to me given public support for 7 ended over four years ago. 
It's probably worth a preemptive email to the users list so we don't surprise 
anyone.

-ck

On Tue, Jul 30, 2019, at 19:56, Matt Sicker wrote:
> I’d be alright with that as well. 3.0 is a good place for modularization
> and API cleanup.
> 
> On Tue, Jul 30, 2019 at 18:55, Remko Popma <[email protected]> wrote:
> 
> > No objections from me.
> > Remko
> >
> >
> >
> > > On Jul 31, 2019, at 8:48, Ralph Goers <[email protected]>
> > wrote:
> > >
> > > I implemented a logging builder pattern in the Log4j API on the master
> > branch. I was able to do that in a backward compatible manner by using Java
> > 8 default methods. Although I could implement those default methods in
> > AbstractLogger in the release-2.x branch, the Logger interface would no
> > longer be backward compatible. In doing some investigation I found
> > https://www.baeldung.com/java-in-2018 <
> > https://www.baeldung.com/java-in-2018> which showed Java 7 usage to be
> > down to about 5%.
> > >
> > > I still don’t see us releasing 3.0 very soon because more modularization
> > work is required. So I am now wondering if we should just make the minimum
> > requirement for new Log4j 2 2.x releases to be Java 8.
> > >
> > > Thoughts?
> > >
> > > Ralph
> >
> -- 
> Matt Sicker <[email protected]>
> 

Reply via email to