Provide a changelog

[tomkerkhove]

We should provide a changelog which talks about:

• New features shipped in a release
• Fixes shipped in a release
• Features/Scaler versions that are deprecated

Use-Case

As a user, it's important to know what has changed in the newer versions than what you are running and if you can move forward.

We already have GitHub releases which discusses most of them but I think it would be nice to have something similar to what Promitor does.

Over there I provide both GitHub releases and a changelog.

The reason why I've introduced the changelog is that not everybody is a GitHub expert nor does GitHub Releases give a good way of keeping track of deprecations. I don't expect those to come next week but over time we'll deprecate specs, scaler versions and more.

Proposal

Introduce a changelog website based on Hugo (example) or a CHANGELOG.md.

[tomkerkhove]

Happy to pick this up if we decide to go forward.

[tomkerkhove]

What do you think @jeffhollan? We need this mainly for deprecation management imo, first example is #621

[ppatierno]

I think it's important having a changelog, so +1 from me. Thanks for raising this @tomkerkhove !

[anirudhgarg]

Genuine question. For every release we have detailed release notes - aren't they enough ?

[ppatierno]

@anirudhgarg are you talking about the list you provide in the "releases" section for each release? If yes, I agree with you but sometimes it's useful having a CHANGELOG.md file in the repo even for "searching" purposes. The release notes you mentioned could just be a "mirror" of that file.

[tomkerkhove]

As mentioned before it is not one or the other but they are complimentary.

The big difference is that a Changelog gives a full history without having to go through all releases. Customers can then easily see what has changed in comparison with their version.

The most important reason why I propose this is for deprecations. We have just deprecated something, but if you are not actively watching every release you will miss this.

In terms of the how, frankly I think it should be under keda.sh as that is the product documention. A lot of folks go to our repo for details, but not everybody.

If you ask me, changelog.keda.sh or keda.sh/changelog would be best option.

[tomkerkhove]

Was discussed at the standup and agreed to provide a CHANGELOG.md