Release Notes Generator

Overview

Create clear, audience-appropriate release communications that help users understand and adopt new capabilities while providing technical teams with necessary details.

Core principle: Release notes are adoption tools, not feature lists. Help users understand the value and how to use it.

When to Use

•Preparing for product release
•Communicating feature updates
•Documenting breaking changes
•Creating internal changelog

Output Format

yaml

release_notes:
  version: "[X.Y.Z]"
  release_date: "[YYYY-MM-DD]"
  release_type: "[Major | Minor | Patch]"
  
  summary:
    headline: "[One sentence about most important change]"
    user_impact: "[How this affects users]"
  
  audiences:
    user_facing:
      highlights:
        - title: "[Feature name]"
          category: "[New | Improved | Fixed]"
          description: "[Benefit-focused description]"
          how_to_use: "[Brief getting started]"
          learn_more: "[Link to docs]"
      
      improvements:
        - "[Smaller improvement 1]"
        - "[Smaller improvement 2]"
      
      fixes:
        - "[Bug fix written as 'Fixed: issue description']"
    
    technical:
      breaking_changes:
        - change: "[What changed]"
          impact: "[Who is affected]"
          migration: "[What to do]"
          deadline: "[If applicable]"
      
      api_changes:
        - endpoint: "[Endpoint affected]"
          type: "[Added | Changed | Deprecated | Removed]"
          details: "[Specifics]"
      
      deprecations:
        - feature: "[What's deprecated]"
          replacement: "[What to use instead]"
          removal_date: "[When it will be removed]"
    
    internal:
      changelog:
        - "[Technical change 1]"
        - "[Technical change 2]"
      
      known_issues:
        - issue: "[Known issue]"
          workaround: "[Temporary solution]"
          fix_expected: "[When expected]"
      
      metrics_to_watch:
        - "[What to monitor post-release]"

Audience-Specific Formats

User-Facing (Marketing/Product)

markdown

# What's New in [Product] [Version]

## 🚀 [Headline Feature]
[Benefit statement—what users can now do]

[Getting started in 2-3 sentences]

[Screenshot or GIF if applicable]

## ✨ Improvements
- **[Feature area]**: [Improvement description]
- **[Feature area]**: [Improvement description]

## 🐛 Bug Fixes
- Fixed an issue where [user-perceptible problem]
- Fixed an issue where [user-perceptible problem]

---
Questions? [Contact support](link)

Technical (Developer/API)

markdown

# [Product] v[X.Y.Z] Release Notes

**Release Date:** [Date]
**Type:** [Major/Minor/Patch]

## ⚠️ Breaking Changes
- **[Change]**: Migration required. See [migration guide](link).

## API Changes
### Added
- `POST /endpoint` - [Description]

### Changed
- `GET /endpoint` - Now returns [change]

### Deprecated
- `GET /old-endpoint` - Use `/new-endpoint` instead. Removal: [date]

## Migration Guide
[Step-by-step instructions]

Internal (Team)

markdown

# v[X.Y.Z] Internal Changelog

## Summary
[One paragraph context]

## Changes
- [Commit/PR reference]: [Description]
- [Commit/PR reference]: [Description]

## Known Issues
- [Issue]: [Workaround], fix in [version]

## Post-Release Monitoring
- Watch [metric] for [expected behavior]
- Alert triggers: [conditions]

Writing Guidelines

Do's

Guideline	Example
Lead with benefit	"Create reports 50% faster with..."
Use active voice	"We added..." not "It was added..."
Be specific	"CSV export now supports 100K rows"
Link to details	"Learn more in our [docs]"

Don'ts

Avoid	Instead
Internal jargon	User-understandable terms
"Various improvements"	Specific improvements
Overexcitement for small fixes	Proportional enthusiasm
Hiding breaking changes	Prominent documentation

Version Semantics

Version Change	User Expectation	Release Note Focus
Major (X.0.0)	Breaking changes, major features	Migration, new capabilities
Minor (x.Y.0)	New features, no breaking changes	New features, improvements
Patch (x.y.Z)	Bug fixes, small improvements	What was fixed

Breaking Change Communication

Template

yaml

breaking_change:
  what_changed: "[Clear description of change]"
  why: "[Reason for the change]"
  who_affected: "[Which users/integrations]"
  action_required:
    before_upgrade:
      - "[Step 1]"
      - "[Step 2]"
    after_upgrade:
      - "[Step 1]"
  timeline:
    deprecated: "[Date]"
    removed: "[Date]"
  help:
    documentation: "[Link]"
    support: "[Contact]"

Release Checklist

• Version number follows semantic versioning
• User-facing notes are benefit-focused
• Technical notes include all API changes
• Breaking changes are prominently documented
• Migration guidance is actionable
• Links to documentation are included
• Internal known issues documented
• Monitoring guidance for team