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