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
I wrote a post with more about this at
I've also started a forum thread for discussions with the WildFly user
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
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
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
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
WildFly Project Lead