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