Add release notes document

[johngmyers]

Description

This is a proposal for a procedure to collect release notes.

The items in the "Other changes" section might be giving too much detail.

Fixes #3925

Checklist

• Unit tests updated
• End user documentation updated

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from johngmyers. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[johngmyers]

/cc @Raffo
/cc @mloiseleur

[mloiseleur]

This is clearly nice and readable.
As long as we don't ask all PR authors to update it, maybe it can work.
At least, we can try.
/lgtm

[Raffo]

@johngmyers can you add some more info on who's supposed to edit the release notes ? Is it the author of a PR or is it us maintainers? If the PR author, how do we ensure programmatically that the release notes are there? And what do we do with them at release time? Copy them instead of the automatically generated release notes or prepend those to avoid missing information? I think with more clarifications we can make the process of contributors, reviewers and people drafting release a bit better.

[johngmyers]

I'm basing this loosely on what we do for kubernetes/kops. Ultimately it's up to the maintainers to make sure it has necessary information, but it's reasonable for reviewers/approvers to ask authors to include a release note in the PR.

The notes should be built up as we go so we don't have to do a big edit job at release time. I don't think we're at a volume where we need to do this programmatically.

In kops we prepend the release notes to the automatically generated changelog for minor releases. Patch releases only have the automatically generated changelog, as such releases only have cherrypicks.

[Raffo]

Ok, cool. Can you add that information that you posted here to the release process document so that's easy to know what to do?

[k8s-ci-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kundan2707]

v0.14 already release so please update release notes with latest one

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[mindw]

/remove-lifecycle stale

The release text is limited in size and is cut mid way.
Having the autogenerated release notes dumped to a file sorted by type would be a great help!.

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[mindw]

/remove-lifecycle stale