vault/changelog
Vault Automation c2c89dff84
changelog: add hash link to changes that originate from enterprise (#8745) (#8775)
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
2025-08-20 17:03:19 -06:00
..
2024-09-10 16:59:08 +00:00
2025-04-16 14:10:17 -04:00
2024-06-04 10:19:18 -07:00
2024-04-30 10:47:45 -04:00
2024-02-14 11:52:34 -06:00
2024-01-11 15:19:16 -06:00
2024-01-24 18:04:44 +00:00
2024-02-14 11:52:34 -06:00
2024-02-20 11:42:59 -08:00
2024-02-26 09:02:05 -07:00
2024-02-26 20:19:35 +00:00
2024-03-28 13:45:43 -05:00
2024-04-09 12:35:39 -07:00
2024-04-12 22:13:45 +00:00
2024-05-27 15:03:59 -04:00
2024-05-07 11:34:21 -05:00
2024-07-09 09:36:23 -07:00
2024-06-28 13:12:10 -07:00
2024-08-05 16:26:24 -07:00
2024-08-15 09:26:51 -07:00
2024-08-29 12:17:51 -06:00
2024-10-21 15:12:31 -04:00
2024-10-22 14:57:26 +02:00
2024-11-06 00:52:29 +00:00
2024-12-04 13:23:55 -05:00
2025-01-09 11:58:29 -08:00
2025-01-31 11:11:44 -08:00
2025-02-13 13:41:20 -08:00
2025-04-17 12:59:45 -05:00
2025-04-15 09:36:14 -04:00
2025-04-03 13:19:20 -04:00
2025-04-23 09:27:01 -07:00
2025-05-09 12:26:43 -05:00
2025-05-12 15:01:30 -05:00
2025-06-06 14:47:39 -04:00
2025-07-31 09:45:11 -04:00
2025-08-08 11:56:54 -04:00
2025-08-08 16:15:02 -04:00
2025-08-08 18:11:16 -04:00

changelog

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.
    • 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.
    • improvement - Most updates to the product that arent bugs, 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.

If more than one area is impacted, use separate code blocks for each entry.

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 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."
```