Maintain a version field, similar to upstream info

[bgrant0607]

Something to consider.

kpt has a nice scheme for versioning packages using tags:
https://kpt.dev/book/03-packages/08-publishing-a-package

However, I'd also like to version variants generated from a cloned package. They specify the version of the upstream package they were derived from, in upstream info, but not their own version.

I tried to use an annotation on the Kptfile to track versions, but without special merge handling, it frequently gets clobbered or conflicts on updates by changes to the version annotation in the upstream package. So, at present, I need to choose a different version annotation key for each level of the derivation tree.

kpt pkg get is like git clone. kpt is missing something like github fork. In the case of versioning, it would give the variant its own version number independent of the upstream package.

This could be added in a layer on top of kpt, similar to how github is a layer on top of git, but it may be worth thinking about a first-class variant-spawning model.

[bgrant0607]

Version is important enough to support in a first-class way, but maybe we also need a downstream Info map for arbitrary metadata added in a downstream clone that is not clobbered or conflicting on update.

Cc @justinsb

[bgrant0607]

That distinction may apply to other Kptfile fields also, such as functions. Need to think more about inheritance chains though

[droot]

Need to think more about inheritance chains though

I think kpt should support inheritance chains in first class way because I see that as a common pattern in the pkg workflow. We need to dig deeper in use-cases and ensure packaging commands get, update, {rebase, pull, push...(proposed one)} work well together.

[bgrant0607]

I think inheritance chains should work, by either replacing or combining upstream and downstream sections, as appropriate.

For instance, upon kpt pkg get and update, upstream functions (new section) and downstream functions (the current pipeline) could be combined into the upstream section of the downstream clone.

This approach could help with #2529.