You know, all you have to do to figure out the JDK versions Log4j supports is look at our web site.
Ralph > On Jun 7, 2023, at 9:14 AM, Matt Sicker <m...@musigma.org> wrote: > > If we continue with strong API compatibility in the API and various main > areas, then we can always bump the major version for those, too, or at least > some larger middle version jump. I can never remember which versions of Log4j > 2.x dropped support for various Java versions. > >> On Jun 7, 2023, at 7:01 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> Something like: >> >> 3.0 : Java 11 >> ... Maintenance >> ~3.5 : Java 17 >> >> On Tue, Jun 6, 2023, 06:10 Gary Gregory <garydgreg...@gmail.com> wrote: >> >>> Note that if we decide to go with Java 17 instead of 11, I won't stand in >>> the way ;-) >>> >>> Gary >>> >>> On Tue, Jun 6, 2023, 06:09 Gary Gregory <garydgreg...@gmail.com> wrote: >>> >>>> The case for maven is quite different IMO because it is a development >>>> tool and does not or should not affect the runtime requirements of the >>>> artifacts built. >>>> >>>> Gary >>>> >>>> On Tue, Jun 6, 2023, 03:28 Piotr P. Karwasz <piotr.karw...@gmail.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Mon, 5 Jun 2023 at 18:33, Matt Sicker <m...@musigma.org> wrote: >>>>>> Piotr raised an interesting question recently which deserves a >>>>> dedicated thread here: what should our strategy be for supporting various >>>>> versions of Java? Our current strategy is essentially Java 8 for 2.x and >>>>> Java 11 for 3.x, but with projects like Spring pushing Java 17 as a base >>>>> requirement and Java 21 (the latest LTS release) coming out in September, >>>>> we may want to devise a version support strategy. >>>>> >>>>> A similar discussion is going on the Maven mailing list: >>>>> https://lists.apache.org/thread/woz6pj6686rxmso47zm35vdxs5vt3bqb >>>>> >>>>> Piotr >>>>> >>>> >
