[wildfly-dev] Re: Possible candidate features for the new Feature Development Process

Hi Diana, FYI everyone, this has been discussed quite a bit at https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to... On Fri, Dec 8, 2023 at 7:20 AM Diana Krepinska <dvilkola(a)redhat.com&gt; wrote: It's not handled at a technical level by Paul's management API stability level work I merged last week. At this point the options for something like that are: 1) Upgrade the component in WildFly Preview, via the dependency entries in https://github.com/wildfly/wildfly/blob/main/preview/galleon-local/pom.xml. (This is what we did for many things during the transition from EE 8 to EE 9.). That's a pain though for something with as many artifacts as Elytron. It also doesn't make the feature available to users of standard WildFly. 2) Have the elytron feature configurable and use the subsystem to turn it off if the server is not at the appropriate stability level. We need an answer for this kind of use case. A potential one is to create different WildFly Channels channels for different stability levels and the user then provisions using the appropriate channel. We'd need to get the UX around that right. For example, many preview features might work just fine without requiring use of a separate channel to provision. Others might be like yours and not involve any integration code change, and just need the channel. Others might be a mix; e.g. a new preview-level attribute that only functions correctly if there is an upgraded component. How does the user know what to do? From the chat discussion it sounds like there is a way to deal with this. It's a workaround though. -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His