Introduce version in the trigger spec

[tomkerkhove]

Introduce version in the trigger spec so that we can release new versions of the trigger specification without breaking customers.

This allows us to introduce new ways of describing things without having messy documentation and is easier to troubleshoot.

Use-Case

When a scaler decides to change things around by renaming fields, moving them around or introduce breaking changes there is no easy way to see the difference as a customer.

With clear versioning it would be more straight forward and the documentation can be built around it.

Current

triggers:
  - type: kafka
    metadata:
      brokerList: kafka.svc:9092
      consumerGroup: my-group
      topic: test-topic
      lagThreshold: '5'

Proposal

We could add a version to the trigger spec:

triggers:
  - type: kafka
    version: v1
    metadata:
      brokerList: kafka.svc:9092
      consumerGroup: my-group
      topic: test-topic
      lagThreshold: '5'

Impact

The impact should be fairly minimal

• Configuration parsing should be able to coop with this
  • When no version is specified v1 should be assumed
• Documentation should be updated
• Releases should note if new versions are released

[tomkerkhove]

We should also look at versioning scalers independently from the core, but that might be another issue.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed due to inactivity.

[tomkerkhove]

Re-opening as I think it's time to do this.

[stale]

This issue has been automatically closed due to inactivity.

[JorTurFer]

I think this could be a huge headache because we'd have potentially twice or 3 times more code to maintain. I'm not saying no to this, but before starting with this, I'd like to have the versioning lifecycle defined and what users can expect from each version.
Are we going to apply backports with fixes or we only actively maintain latest versions? What about e2e tests? How long are we going to support old versions? Is our documentation page ready to offering this feature?
I see the potential of this feature, and it could be a nice improvement, but maybe we should define the surrounding things before. WDYT?

[tomkerkhove]

Oh yes, I'm not saying that we should already implement this straight away but I think we have to do it. It's either this way, or we cannot make breaking changes to triggers unless we bump the API version for our whole CRD.

Before I went in to detail, I wanted to see if we all agree this is something we should do. In terms of duplication, I'd say that this is just something we can isolate from the configuration parsing and share the logic (unless big things are being removed), but I think it's mainly for the way we configure things.

With regards to end-to-end tests, I'd say we support current + current-1, but that's just a proposal