Beta API and Support for Flexible Parameterized Types

[skaegi]

My concern is about API, specifically the golang API and the OpenAPI it might generate for Beta. The current Task and Pipeline types embed the target "run" types as holders where we do parameterization. I think it's likely that before GA Tekton will have more flexible support for parameterization and am trying to figure out how we can avoid a future API breakage -- also see #1530.

I don't think that a change to support a flexible parameterized type would break existing Task and Pipeline definitions -- e.g. CRD level should be correct still as this change would relax requirements in the CRD. I'm more concerned about any guarantee of compatibility with the golang API as for example I can imagine a lot of methods on Task changing.

Does anyone have a good sense about this? Is it possible to declare beta only for our CRDs and be very careful about how we describe them.

[vdemeester]

The current Task and Pipeline types embed the target "run" types as holders where we do parameterization.

I am not sure I get that 🤔.

Does anyone have a good sense about this? Is it possible to declare beta only for our CRDs and be very careful about how we describe them.

The beta API is about the CRDs and the CRD only — the field and their meaning. How the struct are "implemented" (aka a go struct, a java bean, a rust struct, …), is a different beast and, as far as I understand, isn't cover by the beta support level. This mean we could change the entire struct (or even the language we use) and still support the API.

So for me it's a given, the "beta api declaration" is about the CRD, not the golang API. This is also a reason why I feel better having the "beta api release" not a 1.0, because then, this would make the assumption that the golang API is stable to (or at least is changed in a backward compatible way).

/area api
/kind question

[skaegi]

Ok great. I think we can close this then.