Write Developer-Focused Release Notes and Changelogs
A skill for writing changelogs, breaking-change announcements, and deprecation notices developers actually read and trust.
Why it matters
Create release notes, changelogs, and product update communications that developers actually read and care about, building trust and demonstrating product momentum while clearly communicating breaking changes, deprecations, and new features.
Outcomes
What it gets done
Format changelogs using semantic versioning with Added, Changed, Deprecated, Removed, Fixed, and Security categories
Write breaking change announcements with migration guides, timelines, and clear impact assessments
Communicate API versioning lifecycles and help developers choose appropriate version pinning strategies
Transform vague update notes into specific, contextual entries with performance metrics and troubleshooting links
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-changelog-updates | bash Overview
Changelogs and Product Updates Developers Care About
This skill covers writing developer-facing changelogs, breaking-change announcements, deprecation notices, and coming-soon anticipation posts, following the Keep a Changelog format and semantic versioning conventions. Use it when writing release notes, versioning explanations, breaking-change announcements, or deprecation notices for a developer-facing product. Calibrate tone via the developer-audience-context skill first.
What it does
This skill produces changelogs and product update communications that developers actually read, treating release notes as developer communication and a marketing moment rather than plain documentation. It covers the Keep a Changelog format - an Unreleased section, dated version entries, and Added, Changed, Deprecated, Removed, Fixed, and Security categories - with concrete good-versus-bad entry examples emphasizing specificity, such as a stated percentage improvement rather than a vague claim, issue context, links to docs or migration guides, and stated impact for breaking changes. It defines what to always include, such as API and SDK changes, breaking changes, and security fixes even if described vaguely, versus what to consider, like performance improvements, developer-experience changes, and infrastructure updates, versus what to skip or batch, like internal refactoring, minor dependency bumps, and typo fixes. It covers versioning communication: explaining semantic versioning to users, version-pinning guidance comparing caret, tilde, and exact pins, and API version lifecycle communication with current, legacy, deprecated, and sunset states shown in a lifecycle table. For breaking changes, it provides a full announcement template covering affected versions, timeline, what's changing and why, who's affected, before-and-after code samples, a migration guide link, and a phased rollout timeline from beta to sunset, plus a broader communication cadence - announce six months out, release a migration path at three months, send direct emails at one month, a final reminder at two weeks, then a stragglers follow-up a week after the change lands. Deprecation notices are covered at three levels: in-code warnings with a docstring directive, API-level Deprecation and Sunset HTTP headers plus a response body notice, and changelog entries naming the sunset date and post-sunset behavior. Building anticipation covers coming-soon previews with beta or waitlist links, release-cadence communication that sets explicit expectations, and turning major launches into week-long events with a launch day, live coding session, migration office hours, community showcase, and beta-tester acknowledgment. Distribution guidance maps channel to audience and content depth, from a full changelog on GitHub Releases and docs down to highlights-only social posts, with example email templates for both regular releases and breaking-change notices.
When to use - and when NOT to
Use it when writing release notes, changelogs, versioning explanations, breaking-change announcements, deprecation notices, or anticipation-building coming-soon posts for a developer-facing product. Review the companion developer-audience-context skill first to calibrate tone and detail level to how the specific developer audience prefers updates.
Inputs and outputs
Given a set of shipped or upcoming changes, it produces a formatted changelog entry, a breaking-change announcement with timeline and before-and-after code, a deprecation notice in code, API-header, or changelog form, or an anticipation or launch-event communication, matched to the appropriate distribution channel.
Integrations
The Keep a Changelog format and Semantic Versioning conventions; changelog-generation tooling such as Conventional Commits, semantic-release, and changesets; distribution through GitHub Releases, developer newsletters, Twitter/X, and Discord or Slack; and related skills for SDK versioning, docs-as-marketing, developer community channels, and developer metrics.
Who it's for
Developer marketing and DX teams writing release communications that need to build trust and momentum with a technical audience, rather than treating changelogs as an afterthought or dumping raw commit messages on users.
Source README
Changelogs and Product Updates Developers Care About
When to Use
Use this skill when you need create release notes and product updates that developers actually read and care about. This skill covers changelog formatting, versioning communication, breaking change announcements, deprecation notices, and building anticipation for new features. Trigger phrases: "changelog",...
Release notes are developer communication, not documentation. When done well, they build trust, demonstrate momentum, and turn updates into marketing moments.
Overview
Changelogs serve multiple audiences and purposes:
- Active developers: "What changed that affects my integration?"
- Evaluating developers: "Is this product actively maintained?"
- Developer advocates: "What's worth sharing with my audience?"
- Your team: Historical record of what shipped and when
This skill covers creating changelogs that inform, build trust, and occasionally delight.
Before You Start
Review the developer-audience-context skill to understand:
- How do your developers prefer to receive updates?
- What changes do they care most about?
- How much detail do they need?
- What's their tolerance for breaking changes?
Your changelog tone and detail level should match your audience.
The Standard Structure
### [Unreleased]
### Added
- New feature in development
### [2.3.0] - 2024-01-15
### Added
- New `analyze()` method for sentiment analysis
- Support for batch processing up to 100 items
### Changed
- Improved error messages with troubleshooting links
- Default timeout increased from 30s to 60s
### Deprecated
- `old_analyze()` will be removed in v3.0.0
### Fixed
- Race condition in concurrent requests (#234)
- Memory leak when processing large files (#256)
### [2.2.1] - 2024-01-08
### Fixed
- Critical security patch for authentication bypass
### [2.2.0] - 2024-01-01
...
Change Categories
| Category | Use For |
|---|---|
| Added | New features, new endpoints, new parameters |
| Changed | Behavior changes, performance improvements |
| Deprecated | Features being phased out (still working) |
| Removed | Features that no longer exist |
| Fixed | Bug fixes |
| Security | Security-related changes |
Good vs. Bad Entries
Good Changelog Entries:
### Added
- New `batch_analyze()` method processes up to 100 items in a single
request, reducing API calls by 90% for bulk operations.
[See docs](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link) (#198)
### Fixed
- Fixed timeout errors when processing files larger than 10MB.
Uploads now stream in chunks, eliminating memory issues. (#234)
### Deprecated
- `legacy_auth()` will be removed in v3.0.0 (scheduled for March 2024).
Migrate to `oauth_auth()` using our [migration guide](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link).
Bad Changelog Entries:
### Added
- New feature
### Fixed
- Fixed bug
- Fixed another bug
- Various improvements
### Changed
- Updated dependencies
Writing Style
Be specific:
❌ "Improved performance"
✅ "Reduced API response time by 40% for list operations"
Include context:
❌ "Fixed issue #234"
✅ "Fixed timeout errors when uploading large files (#234)"
Link to resources:
✅ "New batch API - [documentation](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link) | [migration guide](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)"
Explain impact:
✅ "Breaking: `user_id` parameter renamed to `id`.
Update your code before upgrading."
What to Include
Always Include
API Changes:
- New endpoints
- New parameters
- Changed response formats
- Changed error codes
SDK Changes:
- New methods
- Changed method signatures
- New configuration options
Breaking Changes:
- Anything that requires code changes
- Removed features
- Changed defaults
Security Fixes:
- Even if vague, acknowledge security updates
- Follow responsible disclosure timeline
Consider Including
Performance Improvements:
### Changed
- List operations now 3x faster through pagination optimization
Developer Experience:
### Added
- Error messages now include troubleshooting links
- SDK now validates API keys at initialization
Infrastructure:
### Changed
- New data center in EU (eu-west.api.example.com)
- Increased rate limits from 100 to 500 requests/minute
Skip or Minimize
Internal refactoring:
❌ "Refactored authentication module"
(unless it affects developers)
Minor dependency updates:
❌ "Updated lodash from 4.17.20 to 4.17.21"
(unless security-related)
Typo fixes:
❌ "Fixed typo in error message"
(batch these into "Various documentation improvements")
Versioning Communication
Semantic Versioning Explained to Users
Help developers understand what version numbers mean:
### Versioning
We follow [Semantic Versioning](https://semver.org/):
- **Major versions (3.0.0)**: May include breaking changes.
Check the migration guide before upgrading.
- **Minor versions (2.3.0)**: New features, backward compatible.
Safe to upgrade.
- **Patch versions (2.3.1)**: Bug fixes only.
Always safe to upgrade.
Version Pinning Guidance
Help developers make good choices:
### Recommended Version Constraints
For stability, we recommend:
- `"myapi": "^2.3.0"` - Get patches and minor updates
- `"myapi": "~2.3.0"` - Get patches only
For production systems:
- Pin exact versions: `"myapi": "2.3.0"`
- Review changelogs before upgrading
- Test in staging first
API Versioning Communication
### API Versions
### Current Versions
- **v2** (current): Full support, recommended for new integrations
- **v1** (legacy): Security fixes only, sunset March 2025
### Version Lifecycle
| Status | Duration | What It Means |
|--------|----------|---------------|
| Current | Ongoing | Full support, new features |
| Legacy | 12 months | Security fixes only |
| Deprecated | 6 months | No updates, migration required |
| Sunset | - | No longer available |
### Specifying Version
```bash
curl https://api.example.com/v2/users
#### or
curl -H "API-Version: 2024-01-15" https://api.example.com/users
#### Breaking Changes
#### Breaking Change Announcement Template
```markdown
### Breaking Change: [Brief Description]
**Affects**: SDK v3.0.0, API version 2024-03
**Timeline**: Changes take effect March 15, 2024
### What's Changing
[Clear description of the change]
### Why We're Making This Change
[Honest explanation - better performance, security, consistency]
### Who's Affected
- ✅ Users of SDK v2.x - no action required
- ⚠️ Users of SDK v3.0.0+ - update required
- ⚠️ Direct API users on v1 - update required
### Required Actions
### If you use our SDK:
```python
#### Before (v2.x)
client.old_method(user_id="123")
#### After (v3.x)
client.new_method(id="123")
If you call the API directly:
#### Before
POST /v1/users/123/analyze
#### After
POST /v2/users/123/analyze
Migration Guide
[Link to detailed migration documentation]
Timeline
- Now: v3.0.0 beta available for testing
- Feb 1: v3.0.0 stable released
- Mar 1: v2.x enters legacy support
- Mar 15: Breaking changes take effect in API
- Sep 15: v2.x sunset (no longer supported)
Need Help?
#### Breaking Change Communication Timeline
6 months before: Announce upcoming change
3 months before: Release new version with migration path
1 month before: Send direct emails to affected users
2 weeks before: Final reminder
Day of: Change takes effect
1 week after: Follow-up for stragglers
#### Deprecation Notices
#### In-Code Deprecation
```python
import warnings
def old_method(self, user_id):
"""
.. deprecated:: 2.3.0
Use :meth:`new_method` instead. Will be removed in v3.0.0.
"""
warnings.warn(
"old_method() is deprecated and will be removed in v3.0.0. "
"Use new_method() instead. "
"Migration guide: https://docs.example.com/migrate-v3",
DeprecationWarning,
stacklevel=2
)
return self.new_method(id=user_id)
API Deprecation Headers
HTTP/1.1 200 OK
Deprecation: Sun, 15 Sep 2024 00:00:00 GMT
Sunset: Sun, 15 Mar 2025 00:00:00 GMT
Link: <https://docs.example.com/migrate-v3>; rel="deprecation"
{
"data": {...},
"_deprecation": {
"message": "This endpoint is deprecated",
"sunset": "2025-03-15",
"migration": "https://docs.example.com/migrate-v3"
}
}
Deprecation Changelog Entry
### Deprecated
- **`/v1/analyze` endpoint**: Use `/v2/analyze` instead.
- Migration guide: [link]
- Sunset date: March 15, 2025
- After sunset: Requests will return 410 Gone
Building Anticipation
"Coming Soon" Announcements
Build excitement for upcoming features:
### Coming in Q2 2024
### Batch Processing API (Beta available now)
Process up to 1,000 items in a single request.
[Join the beta](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
### Python SDK v3.0
Complete rewrite with async support, type hints, and 50% faster.
[Preview documentation](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
### EU Data Residency
For customers with European data requirements.
[Join waitlist](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
Release Cadence Communication
Set expectations:
### Release Schedule
**SDK Releases**: First Monday of each month
**API Updates**: Continuous (backward compatible)
**Breaking Changes**: Twice per year (March, September)
Subscribe to updates:
- [GitHub releases](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
- [Email newsletter](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
- [Discord announcements](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
- [Twitter/X](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
Feature Launches as Events
Turn significant releases into moments:
### 🚀 SDK v3.0 Launch
We're excited to announce the biggest SDK update in 2 years!
### Highlights
- **50% faster** request processing
- **Full async support** for high-throughput applications
- **Type hints** throughout for better IDE support
- **Simplified auth** - configure once, use everywhere
### Launch Week
- **Monday**: SDK v3.0 stable release
- **Tuesday**: Live coding session (YouTube)
- **Wednesday**: Migration office hours
- **Thursday**: Community showcase
- **Friday**: AMA with the SDK team
### Resources
- [Documentation](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
- [Migration guide](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
- [Video walkthrough](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/changelog-updates/link)
### Thank You
Special thanks to our 47 beta testers who found 23 bugs
and suggested 12 improvements that made it into this release!
Distribution Channels
Where to Publish
| Channel | Audience | Content Level |
|---|---|---|
| GitHub Releases | Developers on repo | Full changelog |
| Docs changelog | All developers | Full changelog |
| Blog | Broader audience | Highlights + context |
| Active users | Summary + action items | |
| Twitter/X | Community | Highlights only |
| Discord/Slack | Engaged community | Discussion + highlights |
Email Templates
Regular Release:
Subject: [Product] v2.3.0 Released - Batch Processing + Bug Fixes
Hey [name],
We just released v2.3.0 with some improvements you'll like:
✨ New batch processing API - handle 100 items at once
🐛 Fixed timeout issues with large files
⚡ 40% faster list operations
Full changelog: [link]
Upgrade guide: [link]
Happy building,
The [Product] Team
Breaking Change:
Subject: ⚠️ Action Required: [Product] Breaking Change on March 15
Hey [name],
We're making changes to improve [X], and you'll need to
update your integration before March 15.
What's changing: [one sentence]
What you need to do: [one sentence]
Full details: [link]
Need help? Reply to this email or join our office hours: [link]
Best,
The [Product] Team
Tools
Distribution
- GitHub Releases: Native to most developer workflows
- Beehiiv/Buttondown: Developer newsletter platforms
- Twitter/X: Quick updates to community
- Discord/Slack: Community discussions
Monitoring
- GitHub Stars/Watchers: Engagement metrics
- npm download stats: Adoption tracking
- Email open rates: Communication effectiveness
Related Skills
- sdk-dx: SDK versioning and migration
- docs-as-marketing: Changelog as documentation
- developer-community: Community communication channels
- developer-metrics: Measuring changelog engagement
- technical-content-strategy: Changelog as content
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.