grouping and versioning of flists

[muhamadazmy]

The current hub lack some important features that we need to support in the new version:

• Right now there is way of having multiple versions of the same flist. Instead the hub uses the full name, which makes all versions of all flists lists flat under the repo name. Instead we should have a different organization structure for the flists as follows

  /<repo>
  /flists 
    - <flist-name>/
        - v1.0
        - v2.0
        - <version> ...

• A full flist name is ALWAYS /repo/flists/<flist-name>/<version> this is how it should be returned in all api endpoints
• Support for creating a group of flists. This feature has only been recently implemented in the hub and is called tags. But because it was an after thought it feels kinda hackish

  /<repo>
  /groups
  - <group-name>/
       - <version>
           - <flist-name> -> /<repo>/flists/<flist-name>/<version>
           - <flist-name> -> /<repo>/flists/<flist-name>/<version>

• A group (has it's own version) is a logical group of a set of flists that are meaningful together (say a solution) a group is not downloadable by it's own but you can easily list all flists inside it and then use the full flist name to download
• Lastly to make the feature set complete is the ability to give multiple tags to a certain group

  /<repo>
  /tags
  - <tag> -> /repo/groups/<group-name>/<version>

• This way we can say that production is pointing to zos/v1.2.3 group which itself has many flists that is part of the setup.

[muhamadazmy]

The APIs to create the flists (either upload or conversion from docker) has to accept

• All resources must have full path of the object, so flists, groups and tags has be fully identified as
  • Flists: /<repo>/flist/<name>/<version> (do we need a default latest version?)
  • Group: /<repo>/group/<name>/<version>
  • Tag: /<repo>/tags/<tag>
• All resources returned via the API has also always to use full path to the resource
• Groups should be created automatically when creating an flist. When an flist is being updated it can also accept an optional (group and version) to be added to in the same repo. Hence there is no api to create or edit the group it's done automatically only via uploading/creating an flist
• Tags on the other hand need to have it's separate API to manage, you can only create a tag and this can be used to modify a tag by pointing to a new group or version (given the full group path)