github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-24 17:59:23 -04:00
Code Issues Projects Releases Packages Wiki Activity

Fix contribution guides release note process (#38965)

Browse source
This commit is contained in:
Tim Roes 2019-06-14 15:27:32 +02:00 • committed by GitHub
parent db7b6878c1
commit c33c8877dd
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

16
CONTRIBUTING.md
View file

@ -483,28 +483,22 @@ node scripts/docs.js --open
### Release Notes Process
Part of this process only applies to maintainers, since it requires access to Github labels.
Part of this process only applies to maintainers, since it requires access to GitHub labels.
Kibana publishes major, minor and patch releases periodically through the year. During this process we run a script against this repo to collect the applicable PRs against that release and generate [Release Notes](https://www.elastic.co/guide/en/kibana/current/release-notes.html).
To include your change in the Release Notes:
1. In the title, summarize what the PR accomplishes in language that is meaningful to the user. In general, use present tense (for example, Adds, Fixes) in sentence case.
1. Label the PR with the targeted version (ex: 6.5).
1. Label the PR with the appropriate github labels:
1. Label the PR with the targeted version (ex: `v7.3.0`).
1. Label the PR with the appropriate GitHub labels:
* For a new feature or functionality, use `release_note:enhancement`.
* For an external-facing fix, use `release_note:fix`. Exception: docs, build, and test fixes do not go in the Release Notes.
* For an external-facing fix, use `release_note:fix`. Exception: docs, build, and test fixes do not go in the Release Notes. Neither fixes for issues that were only on `master` and never have been released.
* For a deprecated feature, use `release_note:deprecation`.
* For a breaking change, use `release_note:breaking`.
To NOT include your changes in the Release Notes, please use label`non-issue`. PRs with the following labels also won't be included in the Release Notes:
`build`, `docs`, `test`, `non-issue`, `jenkins`, `backport`, and `chore`.
To NOT include your changes in the Release Notes, please use label`non-issue`. PRs with the following labels also won't be included in the Release Notes:
`build`, `docs`, `test_*`,`test-*`, `non-issue`, `jenkins`, `backport`, and `chore`.
* To **NOT** include your changes in the Release Notes, please use `release_note:skip`.
We also produce a blog post that details more important breaking API changes every minor and major release. If the PR includes a breaking API change, apply the label `release_note:dev_docs`. Additionally add a brief summary of the break at the bottom of the PR using the format below:
```
# Dev Docs