Description

This ADR should describe how to registry would function. We decided that the easiest approach is really using component versions since they are first class citizens inside of open-component-model. An upper level CV could reference the rest of the CVs which each contain a component version which would ease the mechanism of discovery.

The ADR should contain information on how to approach the subject. One of the alternatives we considered when talking about a registry was to actually build the structure behind it with manifest and index files ala helm.

Make sure that the ADR contains the following most interesting points:

• why the manifest solution was discarded or maybe even not discarded?
• why the component version is a good long term solution that scales well ( because CVs are first class citizens and downloading from CV already exists as a command )
• detail the structure of the top level component and how it would reference the plugins as components
• signing later on will be good and we can use that to verify that the plugin was downloaded from a trusted store
• make sure that using a single component version as root makes sense
• add the ability to define a root component to allow for custom distributors

Done Criteria

• Review of the document
• Enduser Documentation updated (if applicable)
• Internal technical Documentation created/updated (if applicable)