[ https://issues.jboss.org/browse/JBDS-2745?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-2745: ------------------------------------------- I've updated the jira to be a feature request since bugs just gets automatic PM approval. With respect to the issue the main problems with these "Experimental" parts are two-fold: 1) Avoid users and support getting confused about what to install/what they have installed. 2) How to avoid earlyaccess bits conflicts with users installation (i.e. new version of a plugin that requires Luna is *not* something that you would like to install and suddenly see some of your essential plugins stop working) #1 we've currently solved by generally not introducing any earlyaccess/beta functionallity via central - there is a big value in being able to say: 'If you installed something via JBoss Central and haven't added any site other than devstudio.jboss.com/updates to your updatesites you are running supported software' (it is simple, understandable and possible to check by users and support) #2 never arises since a) we require the connectors to run on same target platform b) we don't serve updates this way, its all additions (i.e. we don't provide both a egit 2.3 and egit 3.0 plugin from central) My thinking (and i'm not sure its enough) is that we introduce the notion of a certified notion called "earlyaccess" on central connectors (like we have supported, tested, etc.). These connectors should then be shown visually "different", i.e. a yellow/black "Early Access" marker, or yellow tainted background. It depends a bit on how it is shown in central. I would *not* vote for adding an additional tab to Central - it should not get that much space. More like a checkbox in the software/update page which enables/disables "Early access allowed". When users install from this "earlyaccess" category, they should be explicitly warned - you are about to do something non-supported. With that in place users won't by "accident" install earlyaccess via central - they would always have to do something manually. The above covers the installation path, but how about when users have installed a feature - how do we/the user know if they run a supported or non-supported set of features ? Today we can detect if a user have a connector installed or not. We could use this same mechanism to detect if users installed earlyaccess features and then maybe show that someway in central (put a "Experimental" label on the central logo?) Unfortunately this wouldn't be enough since users could install parts manually via updatesite zips, dropins etc. and one version of a feature might be supported where as another one is not. Thus the idea of "blessed features/plugins" came about. Have some representation of plugins/features incl. version ranges we are ok with (supported) and which we consider (earlyaccess). This list would be stored in the discovery plugin (assuming we can make it small enough) Then central could crosscheck this list of plugins/features with what is actually running inside eclipse and mark/highlight wether there are earlyaccess parts PLUS it could report on "foreign" parts which we had no explicit knowledge/info on. To summarize my idea would be: A) add "earlyaccess" notion to connectors on central B) have explicit list of plugins/features that are considered supported vs earlyaccess C) add visual hints and UI to make it clear you installed some of this and you can figure out what you've installed that are experimental. For a full solution we should definitely also add "uninstall" support to central to allow users to remove/rollback experimental parts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira