Re: [log4j] Base Java version requirements for the future?
Something like: 3.0 : Java 11 ... Maintenance ~3.5 : Java 17 On Tue, Jun 6, 2023, 06:10 Gary Gregory 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 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 >> wrote: >> >>> Hi, >>> >>> On Mon, 5 Jun 2023 at 18:33, Matt Sicker 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 >>> >>
Re: [log4j] Base Java version requirements for the future?
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 wrote: > > Something like: > > 3.0 : Java 11 > ... Maintenance > ~3.5 : Java 17 > > On Tue, Jun 6, 2023, 06:10 Gary Gregory 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 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 >>> wrote: >>> Hi, On Mon, 5 Jun 2023 at 18:33, Matt Sicker 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 >>>
Re: [log4j] Base Java version requirements for the future?
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 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 wrote: >> >> Something like: >> >> 3.0 : Java 11 >> ... Maintenance >> ~3.5 : Java 17 >> >> On Tue, Jun 6, 2023, 06:10 Gary Gregory 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 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 wrote: > Hi, > > On Mon, 5 Jun 2023 at 18:33, Matt Sicker 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 > >
