WildFly Calendary Proposal
by Jason Lee
I have a PR open that is a first step in creating a calendar of
WildFly-related events: https://github.com/wildfly/wildfly.org/pull/439
Brian does a great job of emailing the WF dev schedule to this list, but,
for me, it tends to get buried and lost. What I'd love to be able to do is
subscribe to a .ics and have events show up on my calendar. This is a step
toward that. What would be nice is to take that one step further and make
it available in a human-friendly form on wildfly.org as well.
All that said, I would love feedback on the idea itself, the contents of
the calendar, etc. to see if this would be useful to more than just myself.
Additionally, I know we have various community efforts going on at the
moment, so if this overlaps with any of that, I'm happy to roll this into
those efforts.
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP
8 months, 3 weeks
Require SE 17 compiler, compile to SE 11 source and target level
by Brian Stansberry
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
1 year, 7 months
Pushing back the WildFly 32 Beta Release by One Week
by Darran Lofthouse
In general everything is proceeding well with our preparations for the
WildFly 32 Beta release, however with the introduction of the WildFly
feature development process we have some work which is being completed.
It feels a shame that work which is almost ready will miss this Beta
release by strictly applying the time box and we would really like to get
the work we are doing into the hands of our community so we have decided we
will push the release back by one week so some remaining items can be
completed.
WildFly Core is already tagged and we are not planning a further WildFly
Core tag unless a blocking issue is identified, we would now be aiming to
tag WildFly 32 Beta on Wednesday the 3rd April so the release can be
published on Thursday the 4th April.
--
Darran Lofthouse
Red Hat <https://www.redhat.com/>
darran.lofthouse(a)jboss.com
<https://www.redhat.com/>
1 year, 7 months
