Comment 7 for bug 1470211

Fabrizio -

I understand your concern, but until we understand the upgrade path for a MOS + plugin deployment, I do not want to create any sort of inability to install the plugin in any environment. We can revisit this once we have confirmed the behavior of a MOS + plugin environment upgrade.

Specifically: if a customer has a 6.0 environment with a plugin and then we upgrade to MOS 6.1 and there is an incompatibility specified, what would happen to the plugin running on the 6.0 environment? If the user wants to keep both their 6.0 environment and create new environments, how do we account for application plugins which the user might want to install that would be compatible with their original environment? Long-term we want to support the ability for a user to add non-core plugins to an environment after the deployment is complete. There maybe metadata living in the fuel-master node that knows which environments it is capable of supporting and we could map plugin installation to that, but it still wouldn't cover your exact use case (i.e. a user could still install a plugin that is not compatible with their new environment - 6.1 - and get confused/not be able to use it even though it is usable in their old environment - 6.0). This use case needs to be explored thoroughly before we make any decisions on preventing a plugin from installing.

If we are specifying compatibility both in the plugin catalog AND in a deprecation warning, I think that is sufficient for now.