Gary, I think we are not on the same page. I am talking about the "compiler" version, not the "target" version. The version developers use to compile the code, not to run the generated bytecode. We can compile with 17, yet target 11, etc.
For instance, both `logj4-tools` and `log4j-transform` get compiled with 17, yet target 8. Hence 8 users can still consume them. On Mon, Jun 5, 2023 at 10:00 PM Gary Gregory <garydgreg...@gmail.com> wrote: > The latest LTS always view is not realistic if you want users to migrate to > our latest version. My experience is that this will only achieve excluding > apps from migrating because updating the underlying Java platform is > non-trivial for larger enterprise grade stacks. > > Gary > > On Mon, Jun 5, 2023, 14:39 Volkan Yazıcı <vol...@yazi.ci> wrote: > > > I don't have a strong preference for the bytecode version we "target"; 11 > > or 17 is fine. But I would like to point out that we should move the > > compiler requirement to Java 17 and preferably always stick to the latest > > LTS as much as possible. > > > > On Mon, Jun 5, 2023 at 6:33 PM 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. > > > > > > As for relevant features in newer releases, we can rely on > multi-version > > > jars to support specific APIs, but even some of the more relevant ones > > like > > > scoped values and string templates are still in preview mode as of > > version > > > 21. > > >
