Automatically generate release notes for new versions.

[aviv-amdocs]

I can't find any release notes/changelog for versions 15.0 and later...

CHANGELOG.MD only gets up to 14.0.0, the GH release page only says "copy for tag", and the wiki page for "Versioning and Compatibility" lists 15.0.1 and HEAD.

can these be updated please?

[brendandburns]

We need to figure out how to automate this because it is manual now and gets forgotten.

I'll see about automating it and manually writing notes for the existing releases. In the meantime you can look at the list of closed PRs for some idea.

Since we cut a release for each minor Kubernetes version, there are often relatively few changes between releases other than bug fixes and the new Kubernetes API coverage/changes.

[brendandburns]

I just discovered that GitHub has added automatic release note generation (thanks GitHub!).

So there are now release notes. If I'm being honest, they aren't as useful as they could be because many of the changes are Dependabot bumps, but I'll see what we can do to automate this.

But in the meantime, release notes are posted.

[brendandburns]

Here's the docs for the GH Action for release notes:
https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#configuring-automatically-generated-release-notes

[aviv-amdocs]

Yes, those (list of closed PRs) are not useful, when they include almost only non-functional PRs.
Release notes are usually intended for users to understand the actual high-level changes, not just a list of commits.

From my experience, there's no way to "automate" release notes, because there's no way to have a computer understand what is important. The best approach is to consistently update the changelog with every change (including removing outdated stuff).

[brendandburns]

It appears that there is a way to organize the generated release notes via labels on PRs, I'll investigate that when we have time.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[brendandburns]

There's also the changes:github-report maven plugin.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned