chore: update the changelog to reflect the breaking change

[JorTurFer]

I merged a commit with the changelog entry in the wrong section

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)

[JorTurFer]

/skip-e2e

[github-actions]

Thank you for your contribution! 🙏 We will review your PR as soon as possible.

🏖️ Over the summer, the response time will be longer than usual due to maintainers taking time off so please bear with us.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Learn more about:

• Our contribution guide

[tomkerkhove]

I was going to say, please also refer to the GitHub Discussion but looks like we don't have any?

https://github.com/kedacore/keda/discussions/categories/deprecations

[JorTurFer]

I was going to say, please also refer to the GitHub Discussion but looks like we don't have any?

kedacore/keda/discussions/categories/deprecations

This is: #4352 Should I add it also to the changelog?

[tomkerkhove]

We always need to announce deprecations in dedicated discussions for awareness/visibility as per https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#introducing-new-deprecations

[JorTurFer]

Probably we missed that part at that moment :/

[tomkerkhove]

@JorTurFer not really as it's included: https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#custom-resource-definitions-crds

Custom Resource Definitions (CRDs)
Our custom resource definitions (CRDs) have a separate versioning scheme than the KEDA runtime given they have an apiVersion. For this, we follow the official Kubernetes API versioning policy.

KEDA is allowed to make breaking changes to the CRDs, when a new apiVersion is introduced.

[JorTurFer]

@JorTurFer not really as it's included: kedacore/governance@main/DEPRECATIONS.md#custom-resource-definitions-crds

Custom Resource Definitions (CRDs)
Our custom resource definitions (CRDs) have a separate versioning scheme than the KEDA runtime given they have an apiVersion. For this, we follow the official Kubernetes API versioning policy.
KEDA is allowed to make breaking changes to the CRDs, when a new apiVersion is introduced.

This isn't a breaking change in the API because there isn't any change in the CRD. I mean, it's part of the scaler stuff, not the API itself

[JorTurFer]

@JorTurFer not really as it's included: kedacore/governance@main/DEPRECATIONS.md#custom-resource-definitions-crds

Custom Resource Definitions (CRDs)
Our custom resource definitions (CRDs) have a separate versioning scheme than the KEDA runtime given they have an apiVersion. For this, we follow the official Kubernetes API versioning policy.
KEDA is allowed to make breaking changes to the CRDs, when a new apiVersion is introduced.

This isn't a breaking change in the CRD because there isn't any change in the CRD. I mean, it's part of the scaler stuff (is a change in the metadata section, that it's map[string]string, we have just deprecated and removed a key on the map), not the API itself. I meant that we missed the part of opening the discussion

[tomkerkhove]

Everything that is part of the CRD is subject to that rule IMO, even if it's part of the metadata. If we get rid of it, there is impact on end-users so it has to follow the guidance

[JorTurFer]

That's the point, it's not part of the CRD, the field that has removed isn't defined in the CRD spec.
Will this affect to users? Yes. Does this affect as if we would have changed something of the starting parameters? Yes too.
I mean, I consider a CRD change that requires api change when the CRD OpenApi changes, but this isn't the case (but maybe I'm wrong)
WDYT @zroubalik ?
We are in time to rever the change if you think too that it's not allowed by the deprecation policy

[tomkerkhove]

This is where I don't agree; it's not because it's not in the CRD spec that we can just break people.

Will this affect to users? Yes. Does this affect as if we would have changed something of the starting parameters? Yes too.

This basically confirms that it's a breaking change so it has to comply in my opinion. The only reason why we don't have it in the CRD schema is because of the technical implications given metadata is freeform because of all the various trigger types.

Still, it is configuration that end-users use that we cannot break (and also why I keep saying we need #2359 :))

[JorTurFer]

Wait, I didn't merge this PR. Actually IDK why it was merged O.O
@zroubalik Could you share your thoughts about if this is a breaking change or not? if you both think that it's a not allowed change, I'll revert this commit (sorry again, IDK if I merged it by error, the auto merge, or wtf) and the feature removal.