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!

[sleepyfoodie]

currently working on this with @skl

[skl]

@sleepyfoodie and I have been working on automating GitHub releases (with an auto-generated changelog) based on git tags, instead of the release branches which have been used previously. Spoke with @povilasv and agreed that this should simplify future releases, as we won't need to maintain multiple release branches.

As part of preparation for the next release, I have retrospectively created tags and releases for the most recent two release branches:

• https://github.com/kubernetes-monitoring/kubernetes-mixin/releases/tag/version-0.12.0 (no changelog)
• https://github.com/kubernetes-monitoring/kubernetes-mixin/releases/tag/version-0.13.0 (auto-generated changelog)

The reason version-0.12.0 has no changelog is because it can't easily be automatically generated, as many of the previous release branches have diverged. However, version-0.13.0 is the first release to have a full changelog! 🥳

@sleepyfoodie will be raising a PR shortly to introduce the GitHub Action that will automatically create GitHub releases (with changelog), when new tags that follow the pattern version-* are pushed 🙌

I've suggested that the next release should be version-1.0.0, as this repo has been around quite a few years now and is used in production on many clusters.