Hi Rio,
Thanks for the input.
Proposal 2) is interesting. We also have Linux SM - JDK 17 so we have SE
17 coverage that way.
I realize now that soonish when we move std WF to EE 11 we are going to
need testing of the EE 10 variant that we'll provide for a while. So that's
another new use of CI, and probably at least one PR job.
So we have two candidates to drop -- Linux - JDK 17 and Linux MicroProfile
- JDK 17 -- and then we have two new requirements for jobs. Seems like a
match.
Re Proposal 3, SE 17 is still our baseline so personally I'm wary of
dropping all coverage of it in PR testing.
I'm not sure what you're saying re EOL. That page shows lots of vendor
support for SE 17 well into 2027 and quite a bit beyond for years beyond
that.
I know you didn't say drop support for SE 17, but it's valid to start
thinking about it. We'd need to give our community notice before dropping
support for an SE version.
- Brian
On Sat, Feb 21, 2026 at 1:19 PM Richard Opalka via wildfly-dev <
wildfly-dev(a)lists.jboss.org> wrote:
Proposal 3)
Correction: The date of equal ETAs (turning point) will be October 2026
and not April 2026.
Rio
On Sat, Feb 21, 2026 at 6:40 PM Richard Opalka <ropalka(a)redhat.com> wrote:
> Let's assign Brian's PR job changes proposal number 1.
> Below are two other proposals:
>
> Proposal 2)
>
> For both WildFly Core and WildFly PRs, these three jobs are configured:
>
> * Linux - JDK 17
> * Linux - JDK 21
> * Windows - JDK 17
>
> How about replacing "Linux - JDK 17" with "Linux - JDK 25" ?
>
> Proposal 3)
>
> Notice that according to [1] the ETA for JDK 17 EOL (6 months) and
> the ETA since the JDK 25 initial release will be equal in April this year
> so this might be a good reason to switch all WildFly Core & WildFly PR
> JDK 17 jobs to JDK 25 variants?
>
> [1]
https://en.wikipedia.org/wiki/Java_version_history
>
> Rio
>
> On Thu, Feb 12, 2026 at 12:38 AM Brian Stansberry <bstansberry(a)gmail.com>
> wrote:
>
>> We're continuing to progress with qualifying SE 25 as our recommended
>> SE version for WildFly. That's getting close enough that we should
>> look at what we're doing for PR testing. Currently full WF and WF Core
>> are not testing PRs on SE 25. We're relying on nightly jobs to detect
>> problems.
>>
>> A difficulty is CI is a limited resource and we also want to limit our
>> carbon impact, so just adding more jobs for each PR doesn't seem good.
>>
>> Perhaps....
>>
>> On full WF...
>>
>> Replace the "Linux MicroProfile - JDK 17" job with a 'Linux - JDK
25".
>>
>> The "Linux MicroProfile" job runs a subset of tests but with server
>> installation the run the standalone-microprofile.xml config instead of
>> standalone.xml. It basically validates that the presence of the MP
>> stuff in the config doesn't break things. I can't remember the last
>> time that test detected a problem. Probably not the decade. It brings
>> little value.
>>
>> Replacing it with a full -DallTests job will mean more resource
>> consumed per PR though.
>>
>> On Core....
>>
>> Reconfigure "WildFly Core -> Preview Integration Linux- JDK 21" to
use
>> SE 25 instead.
>>
>> That leaves nothing running the core TS on 25 though. Perhaps we could
>> remove the -DskipTests setting in the step in "WildFly Core -> Preview
>> Integration Linux- JDK 21" that builds core.
>>
>> WDYT?
>>
>> - Brian
>> _______________________________________________
>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>> Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
>> List Archives:
>>
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
>>
> _______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
List Archives: ${hyperkitty_url}
--
Brian Stansberry
Collaborative Partner - IBM
Architect, JBoss EAP
WildFly Project Lead
He/Him/His