Create a v1alpha2 apiVersion

[vdemeester]

As discussed in the working group, let's try to create a v1alpha2 apiVersion for 0.9, where we do our main breaking changes, and use our webhook to do the conversion (see #1379).

• This allows user to keep v1alpha1 without getting broken too quickly
• This allows to exercices ourselves on having Investigate use of an admission webhook to ease move to beta #1379 mecanisms
• This prepares us for the beta api (v1beta1) in the releases after (0.10, 0.11 ?)

What this means:

1. the controller works with v1alpha2 struct only
2. the webhook can unmarshall v1alpha1 struct and convert them into v1alpha2 (so that it can be consumed by the controller)

The only question that remains: if I update my current tekton instance, I will have v1alpha1 objects, what should we do with thoses ?

• Update them one shot (at the start of the controller, somewhere else) ?
• Ignore them completely ?

/kind feature
/area api
/area release
/assign

[vdemeester]

Another question rises from that : where should the PipelineResource struct live ?

[bobcatfish]

There was a bit of context to this (and #1379) that I had to ask many questions of @dlorenc (and @jonjohnsonjr ) before I could understand that I want to share for anyone else who doesn't know, specifically more on 1) why we need to be able to bump the API version and 2) why we need to be able to convert between the versions.

I think the TL;DR is that our beta policy/plan suggests following the kubernetes deprecation policy, which has some details that weren't intuitive to me:

• The way that CRDs are implemented right now, it's only possible to store one version in etcd, meaning the CRDs have to be completely recreated when the schema changes
• We want to support painless upgrades but also downgrades, within a moving window of API versions (e.g. you should be able to downgrade from v1beta3 - latest - to v1beta1 without information loss) <-- afaik this doesn't apply to new fields that have been added in v1beta2 or v1beta3

And these have direct benefits: in our current deprecation policy, we assume that users are always aware of what version of Tekton they are using and they are always the ones deciding to upgrade. (Plus we don't support downgrading at all!)

I hadn't thought about what this would mean for folks who are offering services on top of Tekton or managed instances where the user wouldn't be in control of the upgrade (I think @skaegi might have mentioned this but I didn't quite get it). (Once a feature has been deprecated for long enough, the user will still need to make a change so there's still that.)

Anyway probably none of this is news to the people who already understood the problem but I feel like I finally get it :D (And if this explanation is still flawed plz help me refine it!)