Please make proper releases and keep a Changelog

[dserodio]

Making proper tagged releases and keeping a changelog would make managing and upgrading kubernetes-mixin much easier.

I suggest following the keepachangelog.com standard

Thanks!

[povilasv]

What do you mean by proper releases? Keep in mind we need to make a release for each minor release of k8s if it changes metrics, etc.

At the moment, our minor releases follow that. You can see more info in this discussion: https://kubernetes.slack.com/archives/CAX9GU941/p1596108610030400

[s-urbaniak]

I think what is meant to maintain a changelog and a release in the release page of github https://github.com/kubernetes-monitoring/kubernetes-mixin/releases ?

If yes, then I am definitely 👍 on compiling a list of changes for a given release. In addition to bumping a Kubernetes compatibility version we merge in a lot of changes which are worth explicitly being called out.

wdyt @brancz @csmarchbanks @metalmatze @tomwilkie ?

[povilasv]

I think what is meant to maintain a changelog and a release in the release page of github https://github.com/kubernetes-monitoring/kubernetes-mixin/releases ?

If yes, then I am definitely on compiling a list of changes for a given release. In addition to bumping a Kubernetes compatibility version we merge in a lot of changes which are worth explicitly being called out.

That would be awesome!

So do we then require people to add stuff to changelog and how do we make sure that happens?

[s-urbaniak]

@povilasv probably two options:

1. "light-weight": we compile a list of changes which includes simply all merged PRs and their titles since the last branch cut ourselfes.
2. "heavy-weight": we ask contributors to explicitly fill out a changelog.

I feel option 1. is good enough for a starter.

[povilasv]

That would work for one-off, what about new PRs and cherry picks to other branches?

[metalmatze]

Yes, I'm definitely for the first option. We never really intended for these mixins to have any release really. They are mostly a collection of working rules, alerts, and dashboards. We try to maintain compatibility with the last 3 Kubernetes versions and that's about it.
As we have a few releases already, we should try to have a proper changelog indeed.
These changes were pretty much only made by contributors from Red Hat, as we want to have something to reference for each OpenShift version. Other than that, most people (including the kube-prometheus) project just rolls with master anyway.

[povilasv]

👍 first option SGTM.

[github-actions]

This issue has not had any activity in the past 30 days, so the
stale label has been added to it.

• The stale label will be removed if there is new activity
• The issue will be closed in 7 days if there is no new activity
• Add the keepalive label to exempt this issue from the stale check action

Thank you for your contributions!