# Enhanced Release Notes Generation Prompt Generate comprehensive, human-readable release notes for ProxySQL X.X.X using the provided data files. Focus on creating descriptive content that explains what each feature/fix does and why it matters, not just listing PR titles. ## Available Data Files 1. `pr-data.json` - All PR details from GitHub including titles, descriptions, labels 2. `structured-notes.md` - Commit-level organized data with technical details 3. `commit-categories.md` - Commits categorized by type (bug fix, feature, documentation, etc.) ## Requirements ### 1. Overall Structure - Start with a **concise introduction paragraph** summarizing the release's significance - Include a **"Highlights" section** with bullet points summarizing key areas of improvement - Organize changes under logical categories: New Features, Bug Fixes, Improvements, Documentation, Testing, Build/Packaging, Other Changes - Each major section should have a **brief introductory sentence** explaining its theme - End with the release commit hash in backticks ### 2. Writing Style - Write **descriptive paragraphs** for each feature/fix (2-4 sentences minimum) - Explain **what the change does** and **why it matters** to users/administrators - Use **complete sentences** with proper grammar and flow - Avoid jargon without explanation; assume some readers may not be deep technical experts - Maintain a **professional yet accessible** tone ### 3. Technical Formatting - Wrap **all technical terms** in backticks: - Function names: `Read_Global_Variables_from_configfile()` - Variable names: `wait_timeout`, `cur_cmd_cmnt` - SQL queries: `SELECT @@version`, `SELECT VERSION()` - Protocol commands: `COM_PING`, `CLIENT_DEPRECATE_EOF` - Configuration options: `cache_empty_result=0` - Metrics: `PgSQL_Monitor_ssl_connections_OK` - File paths, command names, code snippets - Include **commit hashes (short form)** and **PR numbers** in parentheses after each item - Remove any `[WIP]`, `[skip-ci]`, or similar tags from final output - Use **bold for feature/fix names** followed by commit/PR references ### 4. Section Guidelines #### Highlights Section - 4-6 bullet points summarizing the most significant improvements - Focus on user/administrator benefits - Example: "Enhanced PostgreSQL support with SSL/TLS backend connections" #### New Features Section - Group related features under subcategories (PostgreSQL Improvements, MySQL Protocol Enhancements, Monitoring & Diagnostics) - Start each subcategory with a brief introduction sentence - For each feature: **Bold title**, (commit, #PR), then descriptive paragraph #### Bug Fixes Section - Start with an introductory sentence: "This release addresses several critical issues affecting..." - Group by affected components (MySQL, Monitoring, Security & Configuration) - For each fix: Clearly state the problem, then explain the solution #### Improvements Section - Focus on performance, stability, and efficiency enhancements - Explain the impact (reduced contention, improved compatibility, etc.) #### Other Sections (Documentation, Testing, Build/Packaging) - Include brief introductory sentences for each section - Explain the practical value (better maintainability, expanded platform support, etc.) ### 5. Quality Checklist - [ ] Every feature/fix has descriptive paragraph(s), not just title - [ ] All technical terms properly wrapped in backticks - [ ] Commit hashes and PR numbers included - [ ] Section introductions provide context - [ ] Highlights section gives quick overview - [ ] No WIP/skip-ci tags remain - [ ] Consistent formatting throughout - [ ] Logical grouping of related changes ## Example Format Follow this structure for each feature/fix entry: ``` **Feature Name** (abc1234, #1234) Descriptive paragraph explaining what this feature does and why it matters. Include technical details like `technical terms` in backticks. Explain benefits to users/administrators. ``` ## Output Files Generate the following files: - `ProxySQL-X.X.X-Release-Notes-Enhanced.md` - Main enhanced release notes - `CHANGELOG-X.X.X-detailed.md` - Detailed changelog (optional) - `CHANGELOG-X.X.X-commits.md` - Complete commit list (optional) ## Tone & Audience Write for: 1. **Database administrators** who need to understand new features and fixes 2. **Developers** integrating with ProxySQL 3. **System architects** evaluating ProxySQL for their infrastructure 4. **Open source contributors** understanding the project's direction The release notes should be informative enough for technical decision-making while remaining accessible to those with general database/proxy knowledge.