Composition/Function Revision Semver Versioning

[Mikel-Landa]

What problem are you facing?

Currently our implementation of Compositions involves a main function per composition.

pipeline:
- step: render
  functionRef:
    name: workload
- step: automatically-detect-ready-composed-resources
  functionRef:
    name: function-auto-ready

This means that the main changes between revisions are in the function, not in the composition itself.
While there is a way to pin down the CompositionRevision in use for the XR, as I understand, currently there is no way to do it for functions inside of the Composition itself and even for compositions, revision names are not predictable so you need to first define the revision and then reference it. Also, revisions may not be consistent across clusters.

How could Crossplane help solve your problem?

When pushing a new version for either a composition or a function there should be an optional field that allows specifying a version, ideally semver so then, at composition definition time we could specify the appropriate version:

pipeline:
- step: render
  functionRef:
    name: workload
    version: 1.0.1 #also something like >=1.0.0 for example.
# This would remove the need for fields like `compositionUpdatePolicy` 
# because you could do something like ~0, >0, etc
- step: automatically-detect-ready-composed-resources
  functionRef:
    name: function-auto-ready

This would remove the need for fields like compositionUpdatePolicy because you could do something like ~0/>0 (meaning any version), etc.