I like the proposal!
On Tue, Feb 27, 2024 at 11:48 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
WDYT about doing in main what I did in the EE11 topic branch?
https://github.com/wildfly/wildfly/commit/af6e723a27228884dbc3acdc66be10c...
I did that in EE 11 because we know some EE 11 APIs or impls will require
SE 17. So we need the SE 17 compiler to build with those deps. But we want
our own (WFLY and WFCORE) code to remain SE 11 compatible. So the resulting
binary level must be SE 11 and no language features or SE APIs > 11 can be
used by our own code.
Trying to only do this in the EE11 branch has proven to be a pain, because
a bunch of things like github actions are using SE 11 to build and that
blows up when run against the EE11 branch.
If we did this I'd add a profile that could set the compiler version back
to 11. CI jobs that need to both build the server and run the testsuite on
11 could activate that profile.
Over the course of this year the SE 11 build and test use cases should
become the secondary cases, ones that need special handling Iike activating
a profile. SE 17 should become the 'default, it just works with no special
effort' case. Supporting both EE 10 and 11 in different feature packs is
one reason to keep SE 11 support around, but even with EE 10 our 'typical'
case should become SE 17, not SE 11.
Thoughts?
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
_______________________________________________
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...