Introduce apiVersion for Remediation file

[agrimmer]

Currently, we define the "version" info of the remdiation.yaml with "0.2.0".
I propose to use "apiVersion" and "remediation.keptn.sh/v1alpha2" as value because this would be more k8s-native.
For an example, look here

Definition of Done:

• Spec is updated
• Implementation (go-utils, remediation-service) is updated
• Docs are updated
• Blog post is updated

[christian-kreuzberger-dtx]

I like the idea, though why does it need to be a Kubernetes-like version? It's not a custom resource, nor is stored in Kubernetes.

IMHO we should re-use spec_version (we already have that for SLO and SLI), but change it such that it directly points to our spec repo (github.com/keptn/spec, or even spec.keptn.sh if we introduce a redirect rule), e.g.:

spec_version: spec.keptn.sh/0.1.3

Accessing https://spec.keptn.sh/0.1.3 should then redirect the user to github.com/keptn/spec/tree/0.1.3

edit: depending on the desired result, maybe we should also add /remediation or something to the string, e.g.:

spec_version: spec.keptn.sh/0.1.3/remediation

This would also be something we should consider for cloud-events (our cloud-events only point to a cloud-event spec, not the Keptn spec).

[johannes-b]

I would propose to combine both ideas into: apiVersion:spec.keptn.sh/0.1.3

Reasoning: Regardless of K8s-native or not, the term apiVersion is semantically stronger than spec_version. I like to have API in there because it declares that this is the application programming interface for customizing various settings using this file. The value should then reference the actual version, released on GitHub.