Goal

Update our Release Note format to comply with the https://redhat-documentation.github.io/supplementary-style-guide/#release-notes.

Ensure that the section headings, writing formats, and ticket references follow the style updates.

Description

Release note guidelines in the supplementary style guide were updated. Review the release note type names and ensure that our release notes are in compliance with the naming conventions. https://redhat-documentation.github.io/supplementary-style-guide/#release-notes

Here are the headings/section names:

• New features and enhancements

• Technology Preview features
• Deprecated features
• Removed features
• Known issues
• Fixed issues

For example:

Change:  New and changed features

To:  New features and enhancements

Additional information

This effort is aimed to help customers read and navigate release notes (RNs) across different Red Hat products, and to unite our brand voice. It will also make adopting DITA and AEM easier, and enable further use of AI tools.

• Don’t go back and fix old release note documents to fit the new recommendations.
• Implement guidelines on your next major release.
• Follow the template to build your release note document, however, if your product requires another chapter, create one.
• Keep it consistent with the existing terms (features and issues)
• Keep the grammatical number and capitalization consistent (All chapter and sub-chapter headings should be in plural even if there’s just one RN in the chapter, and use sentence capitalization).
• Preserve the order of the chapters that are based on RN types. Add the new chapter before or after the set of chapters that are based on RN types.
• If there is no entry in a particular chapter or sub-chapter, keep the “empty” sub-chapter heading with an explanation for why that’s the case. For example, if a minor release has no known issues, still include the “Known issues identified in 10.1” sub-chapter and indicate something to the effect of “None”. Ideally, add a bug report link so that customers can easily report newly found issues.
• Similarly, some products only remove functionality on major releases, so for minor releases keep the Removed features chapter with an explanation for why that’s the case. This is for versioned products that publish separate RN docs. If your product differs from this, try to follow as much as possible.