docs: Provide policy on breaking changes & deprecations in KEDA

[tomkerkhove]

Provide policy on breaking changes & deprecations in KEDA

Checklist

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

Relates to #68

[tomkerkhove]

@JorTurFer @zroubalik gentle reminder

[tomkerkhove]

Setting up meeting to discuss open items

[jeffhollan]

looks great! Thank you @tomkerkhove

[zroubalik]

The proposal looks good, but I have finally found out what is the only concern I am having. We should be able to mark some features as experimental/alpha/tech preview... in order to try new things but withough locking us into backwards compatibility requirement.

This way we can try new things and users has clear idea that it is not stable feature.

WDYT?

[JorTurFer]

The proposal looks good, but I have finally found out what is the only concern I am having. We should be able to mark some features as experimental/alpha/tech preview... in order to try new things but withough locking us into backwards compatibility requirement.

This way we can try new things and users has clear idea that it is not stable feature.

WDYT?

It's a good idea, but I'd just add it as a note in the docs, or a table somewhere, simplest as possible

[tomkerkhove]

The proposal looks good, but I have finally found out what is the only concern I am having. We should be able to mark some features as experimental/alpha/tech preview... in order to try new things but withough locking us into backwards compatibility requirement.

This way we can try new things and users has clear idea that it is not stable feature.

WDYT?

It's a good idea, but I'd just add it as a note in the docs, or a table somewhere, simplest as possible

We can't do that @JorTurFer , this has to be baked in to the policy. @zroubalik makes sense. Do you want to take a stab at writing a section on this?

[JorTurFer]

We can't do that @JorTurFer , this has to be baked in to the policy. @zroubalik makes sense. Do you want to take a stab at writing a section on this?

no no, I meant to reflect it in this policy because we should explain these things, but making the implementation simplest as possible, something like adding notes in the feature docs or all together in a section, but now having something super sophisticated for this.

[zroubalik]

The proposal looks good, but I have finally found out what is the only concern I am having. We should be able to mark some features as experimental/alpha/tech preview... in order to try new things but withough locking us into backwards compatibility requirement.
This way we can try new things and users has clear idea that it is not stable feature.
WDYT?

It's a good idea, but I'd just add it as a note in the docs, or a table somewhere, simplest as possible

We can't do that @JorTurFer , this has to be baked in to the policy. @zroubalik makes sense. Do you want to take a stab at writing a section on this?

I can, but no sooner than in a week. I have a ton of stuff to do now 😄

[tomkerkhove]

That's OK - Thanks!

[zroubalik]

Great job

[tomkerkhove]

Great! @ahmelsayed @jeffhollan can you take a last look please?

[tomkerkhove]

We have a majority vote, great to see this getting merged 🎉