add anti-corruption layer into our Knative support

Problem to solve

As DevOps Engineer, in order to make sure that my systems won't break because of 3rd party (e.g. knative) upgrades, I would like a defence mechanism built into the product.

As a Development Team Lead, in order to avoid costly upgrades, I would like to use my code even when it's not the most recent supported version on my cloud provider's end.

As GitLab developers, given that triggermesh manages its own Knative version, we should make sure that Knative is compatible with all the Knative version that we want to support.

Intended users

• Delaney (Development Team Lead)
• Sasha (Software Developer)
• Devon (DevOps Engineer)

Further details

From @grzesiek

we would need an anti-corruption layer. This become possible once we get rid of the tm library. This would allow us to nicely deprecate features and alert users.

Proposal

Permissions and Security

Documentation

Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Links / references