crd: add label with CRD version

[MrFreezeex]

Add a CRD version label that must be updated each time we update the corresponding CRD to facilitate install from go.

In cilium we are doing this for our internal CRDs with some logic that check this label so that we don't accidentally downgrade the version and it would be super useful if we can have directly in the mcs-api repo for MCS-API CRDs to facilitate that check.

When we would be updating the CRD we would basically need to bump the version in config/crd-base and launch make manifest to regenerate the label in the config/crd folder (or just update directly there).

Followup to #115

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: MrFreezeex
Once this PR has been reviewed and has the lgtm label, please assign skitt for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[MrFreezeex]

/cc @skitt @tpantelis

WDYT of this?

[mikemorris]

Gateway API does something similar to this, including the "bundle version" (GitHub release version for the spec, different from the Kubernetes versioning like v1/v1alpha1) and release channel in CRD annotations https://github.com/kubernetes-sigs/gateway-api/blob/main/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml#L6-L7

cc @robscott @youngnick I think maybe one of y'all have mentioned this in a talk about why we do this and how it can be useful?

[youngnick]

Yes, the apiVersion field is a bit coarse-grained and only really tracks breaking changes. So having a schema version that tracks if compatible, additive changes have been made is very useful. That's why we include a bundle version in Gateway API CRDs.

[youngnick]

I'd also recommend noting the procedure down in some release instructions somewhere - otherwise it's easy to forget.

[MrFreezeex]

I'd also recommend noting the procedure down in some release instructions somewhere - otherwise it's easy to forget.

Hmm well there's not really a properly defined release so far, but maybe this could be the same as the git tag which would make it an actual release? It would also mean that we would want to make a new release/git tag almost every-time we change the CRD. WDYT @skitt?

[lauralorenz]

Triage notes:

• This changes our release machinery because we would have another label to update; when/how do we do that exactly we ask ourselves? Mention that more frequent release is ok. We think this is not necessarily blocking and we want to talk to @skitt about this who has the most release experience here
• This proposal is based on how cillium does it today, so that is also prior art
• There is a specific annotation that Gateway API uses and we could copy that and there is some positivity about that - though the Gateway API "bundle" is not required by vendors to be implemented and may have a slightly different semantic meaning than what Arthur is suggesting. This is a naming bikeshed conversation :)

[skitt]

Since we want to track changes, I think the version should be bumped whenever there’s a change — so the bump should be part of the PR making the change, not part of the release. This also means that the CRD version won’t be the same as the project tag, but that’s fine.

We’ll use a version triplet in the same style as Gateway API.

[MrFreezeex]

I updated the PR to start from v0.1.0 since it's not correlated with this repo version (and also adding the v prefix like GW-API). It's very similar to GW-API the only thing is that GW-API use the term "bundle-version" and this is proposing the term "crd-schema-version".

I feel like since it's not part of the release and that GW-API has different bundles (standard, experimental) the term "crd-schema-version" is better suited since I think we are in slighly different scenario than GW-API.

But I don't feel strongly about it so I'm happy to change the term if this means landing this faster and/or that "bundle-version" (or something else) is better liked (cc @mikemorris).