I think if the event type was more generic, and the version would be stored on among the metadata of an event (instead of the event type itself) we have a cleaner design. In CloudEvent this could be done via an extension.
The same approach is now also take by the CNCF xregistry (spin-off from CloudEvents), event/message definitions can be grouped, and each definition/message (aka event) can have its own version as metadata/property:
https://github.com/xregistry/spec/blob/main/message/spec.md
dibyom
commented
8 months ago
Feature request
I see that there are a couple of Tekton events, that have their version hard coded into their type/fqn. See: https://github.com/tektoncd/triggers/blob/176dc0f7eef61e030cf8e173cf5854b61add8589/pkg/reconciler/events/event.go#L25-L35
I think if the event type was more generic, and the version would be stored on among the metadata of an event (instead of the event type itself) we have a cleaner design. In CloudEvent this could be done via an extension.
The same approach is now also take by the CNCF xregistry (spin-off from CloudEvents), event/message definitions can be grouped, and each definition/message (aka event) can have its own version as metadata/property: https://github.com/xregistry/spec/blob/main/message/spec.md