Java SE 21 is due to go GA next week, and SE 11 support from various vendors is starting to ramp down a bit, so I'd like to discuss a bit plans around SE. For some context, please refer to the "Java SE Support" section in https://www.wildfly.org/news/2023/07/21/WildFly29-Released/. A variant of that section is part of every major/minor release announcement and I try and wordsmith it carefully. First, I'm definitely happy about how for a long time now we've been able to use the kind of language I use there about SE 20 for each WF release with respect to the most recent SE GA release. We've done a good job of keeping up with SE. Kudos to Richard Opalka for keeping on top of that, testing and applying fixes well ahead of time. Thanks too to Ken Wills for keeping CI up to date. It's looking good for being able to use the kind of language I used for SE 20 and WF 29 with SE 21 and WF 30. The nightly jobs on CI look good. And we're actually running quite a few more of them than we do with most new SE versions. That said, my instinct is for WF 30 I should modify my standard "Our recommendation is that you run WildFly on the most recent long-term support Java SE release" language, as SE 21 will be too new and our experience too limited to be able to make such a statement. Seems like we should stick to SE 17 as the recommendation. One reason for that is we should confirm with more of the component projects we integrate how they feel about their own SE 21 support. Thoughts? Second topic is SE 11 support. I've signalled in the last couple release announcements that our support for SE 11 will likely come to an end in the next year. For WF 30 I'm tempted to say it will likely be the last release where we support SE 11, phrased in a way to imply that supporting it in January's WF 31 is possible. I expect with the release of SE 21 we will start to see some of the components we integrate move beyond SE 11, so we need to be ready. As a bit of a hedge though I think for WF 31 we should stick with SE 11 as the source level for WildFly, WildFly Core and various component projects that are in the wildfly org. I don't have the sense that we have urgent needs to move beyond that in the next few months, Thoughts? It's great to see the Java ecosystem continue to move forward. Best regards, -- Brian Stansberry WildFly Project Lead He/Him/His