Hi Brian, I have been thinking at a possible evolution of Galleon channels and feature-pack dependencies. This has an impact at the architectural level, and you could think that it is not an idea to follow. That is an early idea to acquire feedback... Having a single FP artifact that contains its channel (current) when we want to define multiple channels (20, 21, 22, ...) seems not right. When designing an FP one has not the ability to select the wildfly channel he wants to depend on. He will express the dependency on org.wildfly:wildfly-galleon-pack:22.0.0.Final that is implicitly the default channel.  This is perhaps not a common use-case, depending on the latest wildfly is perhaps what we want. The idea would be to be able to build an FP per channel per release. Using a classifier to identify the channel. As an example, to support 2 channels (default and 22) we would create 2 FP artifacts: org.wildfly:wildfly-galleon-pack:22.0.0.Final, org.wildfly:wildfly-galleon-pack:22:22.0.0.Final The Galleon channel would be evolved to contain the classifier to identify the correct FP artifact, so GA+classifier+version range (and exclude/include patterns). It would not change the syntax of the FPL, we would still use wildfly@community-universe:22, under the hood, the org.wildfly:wildfly-galleon-pack:22:22.0.1.Final would be retrieved with all dependencies properly bound to the correct channels. To properly bind the dependencies to the channel we want we need more metadata. A new XML file to express the channels we want to build FP for is introduced. This file contains mapping of the dependencies producers to the channels to use. This new XML file would be used when building a feature-pack. Would look like something like: <channels>  <channel>      <name>22</name>      <dependencies>        <dependency group-id="org.wildfly.core" artifact-id="wildfly-core-galleon-pack" channel="15">        <dependency group-id="org.wildfly" artifact-id="wildfly-servlet-galleon-pack" channel="22">         <dependency group-id="org.wildfly" artifact-id="wildfly-ee-galleon-pack" channel="22">      </dependencies>   <channel>   <channel>      <name>22.0</name>      <dependencies>        <dependency group-id="org.wildfly.core" artifact-id="wildfly-core-galleon-pack" channel="15.0">        <dependency group-id="org.wildfly" artifact-id="wildfly-servlet-galleon-pack" channel="22.0">         <dependency group-id="org.wildfly" artifact-id="wildfly-ee-galleon-pack" channel="22.0">      </dependencies>    <channel> </channels> At the end of the build we would have 3 FP built, one for the channel 'current', one for the channel 22 and one for 22.0. Exactly the same bits, except the dependency that contains a classifier. The default channel would be used the way it is today (present in the wildfly-feature-pack-build.xml file), no need to have an entry for it in the new xml file. When designing a FP that depend on wildfly, one would then be able to select the channel he wants to depend on by selecting the GAV (+ classifier). User could benefit from this feature and deploy multiple FP with classifiers. So one could then do: install wildfly:current install myfp:latest (that depends on latest wildfly). or install wildfly:22 install myfp:1.0 (that depends on channel 22 of wildfly). or: install wildfly:23 install myfp:2.0 (that depends on channel 23 of wildfly). Something we would not be able to do (and can't do today is): install wildfly:current install myfp:2.0 (that depends on channel 23 of wildfly). Although the myfp:2.0 would work on the latest widfly, there is no relationship (order) between "current" and 23 channel, so we can't identify that the installation is valid. Perhaps we need another evolution there (compatible channels?). So more artifacts, more constraints but seems to bring clearer dependencies tree. JF.