John Belamaric

cc @natasha41575 @mortent @droot @justinsb When choosing to limit ourselves (for now anyway) to a single, sequential numerical version, we discussed the distinction between the version of the *configuration package*...

> @johnbelamaric don't you see a case where a configuration package can consists of multiple source packages? How do you see that working in the above scheme? Are you saying...

Actually it seems this is not what the operator does; rather it handles only the GCP side of the binding. So this raises the priority of this issue.

> I agree with the merge and iterate approach, but I think we should come up with an approach where all the "very alpha" controllers doesn't run by default for...

> One possible challenge with this is that we can not simply use the sha for the regular commit as the resource version, since those will not change when we...

Oh - that said, I lean towards a special porch branch for metadata about a package. But we'll need a thorough evaluation.

Package conditions *might* end up different from actual resource status conditions. I was imagining them as actually set in either the Kptfile or as a their own separate resource. They...

FYI, looks like the best practice is to drive generation based on spec only: https://github.com/kubernetes/kubernetes/issues/67428#issuecomment-456125985

cc @droot @yuwenma @bgrant0607 @justinsb @mortent

Here is a more drawn out description of how Conditions enable collaborative editing of the config, as well as decouple it from roll out: We have the concept of Proposed...