Skip to content

Commit

Permalink
Update notes for CHANGELOG template (#6972)
Browse files Browse the repository at this point in the history
  • Loading branch information
chrisdoherty4 authored Nov 8, 2023
1 parent 8c135ab commit 2c106a6
Showing 1 changed file with 37 additions and 14 deletions.
51 changes: 37 additions & 14 deletions docs/developer/CHANGELOG_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -1,17 +1,39 @@
## [Version]

<!---
* EACH ENTRY SHOULD BE A SUMMARY OF THE CHANGE; BIG CHANGES GENERALLY REQUIRE MORE EXPLANATION.
* EACH ENTRY SHOULD BE ACCOMPANIED BY EITHER A PUBLIC ISSUE OR A PR (PREFER ISSUES OVER PRS).
* REREAD ALL ENTRIES FROM THE USERS PERSPECTIVE. WILL IT MAKE SENSE?
* IF A SECTION CONTAINS NO ENTRIES, REMOVE THE SECTION.
* IF ALL SECTIONS ARE EMPTY, YOU SHOULDN'T BE DOING A RELEASE!
<!--
How to use this template
------------------------
1. Copy the contents into the desired location.
2. If you're creating the GitHub release, remove the ## [Version]
3. Add entries to the various sections ensuring you summarise the change; big changes generally
require more explanation.
4. Append an issue or PR to each entry (prefer issues).
5. If a section doesn't contain any entries, remove the section.
6. Re-read all changes from the users perspective. Ensure the summary is written so that almost
anyone with a foundational knowledge of EKS Anywhere can appreciate what the change means.
7. If all sections are empty, you shouldn't be creating a release.
When gathering feedback and applying suggestions:
* Re-read the suggest edits in the same fashion as (6).
* Double check for duplication, punctuation and grammar (ask for help as needed).
General tips
------------
* Avoid acronyms unless they're accepted industry wide. CRD is domain specific, use Custom
Resource Definition instead. I/O is known industry wide as Input/Output so is fine.
* Use plain language - avoid jargon.
* Keep sentences concise but clear.
-->
## [Version](GitHub URL)

### Must read before upgrade
<!--
Discuss things a user _really_ needs to know before they upgrade. Its the kind of thing that if unread could
be disasterous.
Discuss caveats a user _really_ needs to know before they upgrade. Its the kind of thing that if
unread could be disasterous. Perhaps the user needs to execute some commands before or after
running the upgrade; detail that here.
-->

### Deprecation
Expand All @@ -26,12 +48,13 @@ Highlight Custom Resource Definition and CLI changes (additions go under Feature

### Feature
<!--
Highlight new additions to Custom Resource Definitions, CLI or any tool we provide for customers.
Highlight new additions to Custom Resource Definitions, CLI or any tool we maintain for customers.
-->

### Tool Upgrade
<!--
Highlight all upgrades to tooling. Most of this information comes from the build tooling repo. Format as follows.
Highlight all upgrades to tooling. Most of this information comes from the build tooling repo.
Format as follows:
* Tool Name: <from version> to <to version>
Expand All @@ -50,12 +73,12 @@ Highlight bug fixes for all applications.

### Other
<!--
Highlight any other changes such as tweaks to behavior.
Highlight any other changes that would be useful for the user to know.
-->

### Supported Operating Systems
<!--
List all supported OSs for each provider.
List all supported operating systems for each provider.
-->

| | vSphere | Bare Metal | Nutanix | CloudStack | Snow |
Expand Down

0 comments on commit 2c106a6

Please sign in to comment.