Hi WildFly developers, Over the course of 2021 we've been working hard on WildFly, both on improving our EE 8 server and on using WildFly Preview to get ready for the transition to EE 10. A question throughout has been when's the right to shift our primary development efforts toward the EE 10 server. There have been a number of conversations about this over the last couple months, and it seems clear that now is the time to do this. Producing a time-boxed WildFly 27 in March that is both EE 8 (standard WF) and EE 9+ (WF Preview) is not an effective use of our resources; we'll just end up being slow on EE 10 while not really being able to deliver all that many non-EE 10 related features. So, instead we're going to target WildFly 27 at EE 10 support in standard WildFly. 27 won't be a quarterly time-boxed release; instead it will be feature boxed, done when we are satisfied with its feature set (primarily EE 10). I wrote a post with more about this at https://www.wildfly.org/news/2022/01/21/WildFly-2022/ I've also started a forum thread for discussions with the WildFly user community: https://groups.google.com/g/wildfly/c/APYM_GvaHLs My thought was to use this thread / this list for discussions about the actual development strategy. And of course Zulip is a good place to chat. We will be producing a 26.1 in March. The 26.x branch that we used for today's WildFly 26.0.1 will be used for that. That means any features or fixes for 26.1 will need to be applied to main first and then ported to 26.x. (For WildFly Core, it's the 18.x branch that will be used for WildFly 26.1.) I don't expect anyone to port all features and fixes to 26.x; our focus IMHO should be on main. But 26.1 is a good way to get community bake for new features, and providing bug fixes to our users is always a good thing. In particular we should work to bring in component upgrades that resolve CVEs. 26.1 will be an EE 8 release (9.1+ in Preview) that can run on SE 8. It will be the last such feature release. Because WF 27 is now feature-boxed we can adjust some of the development practices that we've used in WildFly since we started doing the quarterly time-boxed releases. For example, it is permissible to use non-Final component releases in main, although this should be limited to cases where it's necessary for EE 10 work. I'm sure as this work goes along there will be disruptions in our ability to run / pass TCKs. The main branch must always be able to compile/build and the testsuites should pass. If there are situations where particular tests won't be able to function for a period we can discuss disabling them, but any such disabling of tests should be accompanied by a priority Blocker JIRA to get them working again. A key task is the ongoing effort to get native jakarta.* variants of all of our components. I think in the next week or so we should look hard into changing the build to SE 11 and dropping SE 8 builds and testing. We should also drive to eliminate any barrier to compiling with SE 17, so we can more easily add SE 17 CI jobs. Basically I'd like to replace all the current SE 8 CI jobs with SE 11 ones, and then replace the current SE 11 jobs with SE 17. I think it's good to get this shift out of the way early so we're not dealing with it as we start bringing in EE 10 impls and moving the code away from javax.*. Best regards, -- Brian Stansberry WildFly Project Lead He/Him/His