2020-12-01 16:08:19 +00:00
|
|
|
|
# changelog
|
|
|
|
|
|
|
2022-06-06 14:04:48 +00:00
|
|
|
|
This folder holds changelog updates from commit 3bc7d15 onwards.
|
|
|
|
|
|
|
|
|
|
|
|
Release notes are text files with three lines:
|
|
|
|
|
|
|
|
|
|
|
|
1. An opening code block with the `release-note:<MODE>` type annotation.
|
|
|
|
|
|
|
|
|
|
|
|
For example:
|
|
|
|
|
|
|
|
|
|
|
|
```release-note:bug
|
|
|
|
|
|
|
|
|
|
|
|
Valid modes are:
|
|
|
|
|
|
|
|
|
|
|
|
- `bug` - Any sort of non-security defect fix.
|
|
|
|
|
|
- `change` - A change in the product that may require action or
|
|
|
|
|
|
review by the operator. Examples would be any kind of API change
|
|
|
|
|
|
(as opposed to backwards compatible addition), a notable behavior
|
|
|
|
|
|
change, or anything that might require attention before updating. Go
|
|
|
|
|
|
version changes are also listed here since they can potentially have
|
|
|
|
|
|
large, sometimes unknown impacts. (Go updates are a special case, and
|
|
|
|
|
|
dep updates in general aren't a `change`). Discussion of any potential
|
|
|
|
|
|
`change` items in the pull request to see what other communication
|
|
|
|
|
|
might be warranted.
|
|
|
|
|
|
- `deprecation` - Announcement of a planned future removal of a
|
|
|
|
|
|
feature. Only use this if a deprecation notice also exists [in the
|
|
|
|
|
|
docs](https://www.vaultproject.io/docs/deprecation).
|
|
|
|
|
|
- `feature` - Large topical additions for a major release. These are
|
|
|
|
|
|
rarely in minor releases. Formatting for `feature` entries differs
|
|
|
|
|
|
from normal changelog formatting - see the [new features
|
|
|
|
|
|
instructions](#new-and-major-features).
|
|
|
|
|
|
- `improvement` - Most updates to the product that aren’t `bug`s, but
|
|
|
|
|
|
aren't big enough to be a `feature`, will be an `improvement`.
|
|
|
|
|
|
|
|
|
|
|
|
2. A component (for example, `secret/pki` or `sdk/framework` or), a colon and a space, and then a one-line description of the change.
|
|
|
|
|
|
|
|
|
|
|
|
3. An ending code block.
|
|
|
|
|
|
|
|
|
|
|
|
This should be in a file named after the pull request number (e.g., `12345.txt`).
|
|
|
|
|
|
|
|
|
|
|
|
There are many examples in this folder; check one out if you're stuck!
|
|
|
|
|
|
|
|
|
|
|
|
See [hashicorp/go-changelog](https://github.com/hashicorp/go-changelog) for full documentation on the supported entries.
|
|
|
|
|
|
|
|
|
|
|
|
## New and Major Features
|
|
|
|
|
|
|
|
|
|
|
|
For features we are introducing in a new major release, we prefer a single
|
|
|
|
|
|
changelog entry representing that feature. This way, it is clear to readers
|
|
|
|
|
|
what feature is being introduced. You do not need to reference a specific PR,
|
|
|
|
|
|
and the formatting is slightly different - your changelog file should look
|
|
|
|
|
|
like:
|
|
|
|
|
|
|
|
|
|
|
|
changelog/<pr num OR feature name>.txt:
|
|
|
|
|
|
```release-note:feature
|
|
|
|
|
|
**Feature Name**: Description of feature - for example "Custom password policies are now supported for all database engines."
|
|
|
|
|
|
```
|
