At the very beginning, Prospero of course comes before the installation, so there does need to be some initial control of stability that's not coming from the installation.
2) This feature is about updating an existing installation. That installation was provisioned with a particular minimum stability. Can this information be preserved in a way that allows Prospero to use it?
Yes, the stability level is a part of the Galleon provisioning definition, it's stored in the .galleon/provisioning.xml. Prospero has an access to that information.
I started down this line of thinking because there shouldn't be any need to start the JBoss CLI or HAL with a particular stability level in order to control the capabilities they expose to users. They connect to a server and can see its stability and can tailor their behavior accordingly. For example if a CLI command or command arg is at preview stability, don't offer it if the server is at community or default.
I guess that would be possible - the argument or operation would still be available to the user when composing the command, but at execution time the user would get an unsupported operation error. I’m wondering if that’d lead to some confusion for the users though if those operations and attributes were available in the help and autocomplete but would not work when executed on the server.
In general I wanted to explore the option to include the notion of stability levels in the Prospero Galleon packs, so that we can provision the installer distribution at either level, but I need to understand more about how those levels are implemented in WildFly and Galleon to do that.