Story #3360
Updated by dkliban@redhat.com almost 7 years ago
***Motivation*** *Motivation* When a single package needs to be introduced to the production environment, it's possible that the repository version X that was used to create the publication in production contains a completely different set of content than the latest repository version Y. Simply adding the new package to the latest repository version will not produce a repository version that is suitable for production. Here are two possible ways to get a single package added to the production environment: 1. Determine which units need to be added to the latest repository version Y and which need to be removed to achieve the same content set as 'production' repository version X. 2. Create a new repository version Z by using information from step 1 + new package. 3. Create a publication from the new repository version. 4. Update the production distribution to point to the new publication. Pros: repository version history is preserved in a single repository Cons: requires user to figure out how to find delta between repository versions 1. Create a 'hotfix' repository. 2. Create a 'hotfix' repository version Z from content in the production repository version + hotfix package. 3. Create a publication from the new 'hotfix' repository version. 4. Update the production distribution to point to the new publication. Pros: not difficult to execute Cons: repository version history is split between original repository and 'hotfix' repository ***Solution*** *Solution* A user should be able to create a repository version by specifying a base version. This would remove the responsibility of finding deltas between repository versions from the user. The /api/v3/repositories/<id>/versions/ API should accept a 'base_version_href'. When specified, the new repository version is created to be exactly like the base version plus any 'add_content_units' and minus any 'remove_content_units'.
.