Skip to main content

Changelog Management Guide

This guide explains how to maintain the CHANGELOG.md and GitHub releases for VibeTunnel.

Overview

We maintain a comprehensive changelog that:
  • Documents all user-facing changes
  • Credits contributors properly with GitHub links
  • Tracks first-time contributors for each release
  • Provides clear, user-friendly descriptions

Using the /changelog Command

The /changelog command in Claude Code analyzes git history to generate comprehensive changelogs:
This command:
  • Analyzes commit history beyond just titles
  • Examines actual file changes to understand user impact
  • Groups changes by category (Features, Bug Fixes, Performance, etc.)
  • Writes user-focused descriptions (not developer jargon)

Changelog Format

Version Header

Categories

  • Features - New functionality
  • Improvements - Enhancements to existing features
  • Bug Fixes - Fixed issues
  • Performance - Speed/efficiency improvements
  • Developer Experience - Build, test, or development improvements

Attribution Format

Every change should credit its contributor:
Format: - Description (via [@username](https://github.com/username)) (#PR)

First-time Contributors Section

For releases with new contributors:

Identifying Contributors

Finding First-time Contributors

Mapping Changes to Contributors

Special Cases

Bot Contributors

Do not highlight bot contributors as first-time contributors or include them in the contributors list:
  • devin-ai-integration[bot]
  • blacksmith-sh[bot]
  • Other *[bot] accounts
Important: Bot contributions should be completely excluded from:
  • First-time contributors sections
  • The main contributors list at the end of CHANGELOG.md
  • GitHub release notes contributors sections
Bot changes can be mentioned in regular changelog entries (e.g., “Added SwiftLint hooks”) but without attribution.

Core Team

Core team members (repository owners) don’t need “(via @username)” attribution unless specifically requested.

Multiple Contributors

If multiple people worked on a feature:

GitHub Releases

Creating a Release

  1. Generate changelog using /changelog command
  2. Review and edit the generated content
  3. Update CHANGELOG.md with the new version section
  4. Create GitHub release:

Release Notes Format

The GitHub release should include:
  1. Highlights - 2-3 major changes
  2. Full changelog - Copy from CHANGELOG.md
  3. First-time contributors - If applicable
  4. Installation instructions - Brief reminder
Example:

Updating Existing Releases

To add first-time contributors to existing releases:

Workflow Summary

  1. Before release: Run /changelog to analyze changes
  2. Review output: Ensure proper attribution and user-friendly descriptions
  3. Update CHANGELOG.md: Add new version section with proper formatting
  4. Create release notes: Include highlights and first-time contributors
  5. Create GitHub release: Use gh release create or web UI
  6. Verify: Check that all contributors are properly credited

Tips

  • Always verify contributor GitHub usernames for correct links
  • Use clear, non-technical language in descriptions
  • Include PR numbers for traceability
  • Group related changes together
  • Highlight breaking changes prominently
  • Credit everyone who contributed, no matter how small

Example Workflow