Bug 1126819

Description of problem:

Users want to make a change to an existing content view. It could be to add a couple puppet modules or update some packages or in the case of composite views, it could be to change a component version. They want to then publish and re-promote that new version directly to the environment the published content view was in, bypassing current restrictions on lifecycle environment promotions.

There are two pieces that we need to solve: first allowing users to make a change to published view. Secondly, giving users the ability to bypass current restrictions on having to promote through environments.


Example use case:

I have a composite view called "composite" which is composed of two views (os and puppet). In my environments, I have:

Dev - composite v2 (os v2 and puppet v1)
Test - composite v2 (os v2 and puppet v1)
Prod - composite v1 (os v1 and puppet v1)

I want to publish and promote a new component puppet v2 to all environments without changing the existing version of os.


Possible solutions:

For problem 1, we could allow users to make revisions or branch the existing views. So in our example use case the user would publish a composite v3 for Dev and Test, and perhaps a composite v2.1 or v3.1 which would contain os v1 and puppet v2 for Prod. The user would then have to promote the view somehow to Prod (see below).

For problem 2, there are a few solutions:

1. One would be to allow promotion of the new composite revision directly to Prod. 

2. Another would be to allow multiple environments to point to Prod so essentially the user could create a "Patch" environment which they could promote through to Prod. 

3. Lastly, we could allow multiple versions per environment so the users would use the same environment path but the environments Dev and Test would contain version 3 and 2.1.