WildFly Release Plans for 2022

Since the WildFly 12 release, the WildFly project has followed a roughly time-boxed development model. Roughly every three months we endeavor to produce a new WildFly major release, with a large set of features, enhancements and bug fixes. We don’t operate on a strict time schedule, but we avoid significant schedule delays just to bring in particular feature or set of features. If a feature doesn’t make a particular release it can just go in the next one a few months later.

The vast majority of the work on WildFly, both for features and bug fixing, is on our main branch, aimed at producing the next WildFly major.

When we release each major we also create a new branch specific to that major. That branch is used to produce one micro (primarily bug fix) release for the major, with the micro usually released about a month after the major. This too is roughly time-boxed. We just released WildFly 26.0.1 today. The number of changes in the micro is typically small compared to what’s gone into main in the same period, as we want to be particularly conservative about introducing bugs or behavior changes in the micro. We’ve been consistently producing these micros since WildFly 17.0.1, and had done a few prior to that as well.

Time-boxed releases work well most of the time but they can be problematic when a large interrelated set of features need to come in as a block. Say, for example, Jakarta EE 10! Trying to fit all of our EE 10 work into a single quarterly release is not looking practical, and using time boxing for EE 10 isn’t conceptually valid, as Jakarta’s work on EE 10 itself isn’t time-boxed.

So, we’ve decided to make WildFly 27 feature-boxed, with EE 10 as the primary feature set. We’ll produce WildFly 27.0.0.Final when we are satisfied that we’ve met our feature goals. When that will be done is uncertain, partly because it depends on when EE 10 itself goes GA. For sure we won’t be done in March, when our next major normally would be released.

Typically for a WildFly major we produce a single feature-complete Beta release a couple weeks before the Final release. It’s likely that for 27 we’ll also produce at least one interim, not-feature-complete release, probably labeled as an Alpha.

I expect WildFly 28 will be feature-boxed as well. My instinct is once the EE 10 work is complete we’ll have a big enough further set of work that is best done as a unit to justify doing another feature boxed release.

Late in 2022 or early in 2023 I’d like for the project to move back to quarterly time boxing. I think most of the time that is the better way to deliver software.

We don’t want to entirely move away from our quarterly feature releases though. We want to make some features available to our users without waiting for WildFly 27, and we want to have a vehicle for releasing some bug fixes. So, in the roughly March timeframe when we would have done our next feature release, we plan to release a WildFly 26.1. However, the feature and bug fix payload for this release will be significantly smaller than what would be included in a typical WildFly quarterly release. Our development efforts this quarter will largely be focused on WildFly 27.

We’ll also do a 26.1.1 release roughly a month after 26.1.0.

If it makes sense we may do a WildFly 27.1 as well, later this year.

When WildFly 27 is released there will be large changes compared to WildFly 26:

So, the WildFly 26.1 release will be the last feature release that support EE 8 and SE 8. With WildFly 27 we’ll have moved on to EE 10, SE 11/17 and MicroProfile 5.

We plan to continue to produce WildFly Preview. The primary use case for it at its inception was as a preview of our EE 9+ support, but from the start it was meant to be a general purpose way of providing a look at things not yet appropriate for standard WildFly, and there’s still a need for that. It wouldn’t surprise me though if the difference between WildFly 27 and WildFly Preview 27 is fairly small, while we focus our energies on completing EE 10.

We’re also strongly considered no longer producing the "Servlet-only distribution" of WildFly that can be found on the download page for each WildFly release. We don’t see much evidence of this distribution being used, Galleon can easily be used to provision an equivalent server, and producing that distribution requires a non-trivial amount of work that could that could be applied elsewhere. I’d like to hear from the WildFly community about this, so I started a thread on the WildFly forum.

If you have questions or want to provide feedback, I encourage you to post on the WildFly forum, on the wildfly-dev mail list or in Zulip chat. I will be starting threads on the forum and wildfly-dev list about this topic.

Best regards,

Brian