Release Manager

What This Skill Does

The Release Manager skill offers tools for managing software releases. It helps with changelog generation, version bumping, and release process orchestration. This skill is designed for engineering teams looking to improve the reliability and predictability of their software releases.

When to Use

Automate changelog generation from commit history. Determine semantic version bumps based on code changes. Assess release readiness with checklists. Plan and coordinate releases with stakeholders. Manage hotfixes for emergency releases. Integrate feature flags for progressive rollouts.

Key Features

Automated changelog generation from git history. Semantic version bumping based on commit analysis. Release readiness assessment with checklists. Release planning and coordination templates. Automated rollback procedures. Feature flag integration for rollouts.

Overview

The Release Manager skill provides comprehensive tools and knowledge for managing software releases end-to-end. From parsing conventional commits to generating changelogs, determining version bumps, and orchestrating release processes, this skill ensures reliable, predictable, and well-documented software releases.

Core Capabilities

Automated Changelog Generation from git history using conventional commits Semantic Version Bumping based on commit analysis and breaking changes Release Readiness Assessment with comprehensive checklists and validation Release Planning & Coordination with stakeholder communication templates Rollback Planning with automated recovery procedures Hotfix Management for emergency releases Feature Flag Integration for progressive rollouts

Key Components

Scripts

changelog_generator.py - Parses git logs and generates structured changelogs release_planner.py - Assesses release readiness and generates coordination plans

Documentation

Comprehensive release management methodology Conventional commits specification and examples Release workflow comparisons (Git Flow, Trunk-based, GitHub Flow) Hotfix procedures and emergency response protocols

Release Management Methodology

Semantic Versioning (SemVer)

Semantic Versioning follows the MAJOR. MINOR. PATCH format where:

MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backwards compatible manner PATCH version when you make backwards compatible bug fixes

Pre-release Versions

Pre-release versions are denoted by appending a hyphen and identifiers: 1.0.0-alpha.1 - Alpha releases for early testing 1.0.0-beta.2 - Beta releases for wider testing 1.0.0-rc.1 - Release candidates for final validation

Version Precedence

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 1.0.0-rc.1 < 1.0.0

Conventional Commits

Conventional Commits provide a structured format for commit messages that enables automated tooling:

Format

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Types

feat: A new feature (correlates with MINOR version bump) fix: A bug fix (correlates with PATCH version bump) docs: Documentation only changes style: Changes that do not affect the meaning of the code refactor: A code change that neither fixes a bug nor adds a feature perf: A code change that improves performance test: Adding missing tests or correcting existing tests chore: Changes to the build process or auxiliary tools ci: Changes to CI configuration files and scripts build: Changes that affect the build system or external dependencies breaking: Introduces a breaking change (correlates with MAJOR version bump)

Examples

feat(user-auth): add OAuth2 integration

fix(api): resolve race condition in user creation

docs(readme): update installation instructions

feat!: remove deprecated payment API BREAKING CHANGE: The legacy payment API has been removed

Automated Changelog Generation

Changelogs are automatically generated from conventional commits, organized by:

Structure

Changelog

[Unreleased]

Added

Changed

Deprecated

Removed

Fixed

Security

[1.2.0] - 2024-01-15

Added

OAuth2 authentication support (#123) User preference dashboard (#145)

Fixed

Race condition in user creation (#134) Memory leak in image processing (#156)

Breaking Changes

Removed legacy payment API

Grouping Rules

Added for new features (feat) Fixed for bug fixes (fix) Changed for changes in existing functionality Deprecated for soon-to-be removed features Removed for now removed features Security for vulnerability fixes

Metadata Extraction

Link to pull requests and issues: (#123) Breaking changes highlighted prominently Scope-based grouping: auth:, api:, ui: Co-authored-by for contributor recognition

Version Bump Strategies

Automatic Detection Rules

MAJOR: Any commit with BREAKING CHANGE or ! after type MINOR: Any feat type commits without breaking changes PATCH: fix, perf, security type commits NO BUMP: docs, style, test, chore, ci, build only

Pre-release Handling

Alpha: 1.0.0-alpha.1 → 1.0.0-alpha.2

Beta: 1.0.0-alpha.5 → 1.0.0-beta.1 RC: 1.0.0-beta.3 → 1.0.0-rc.1 Release: 1.0.0-rc.2 → 1.0.0

Multi-package Considerations

For monorepos with multiple packages: Analyze commits affecting each package independently Support scoped version bumps: @scope/package@1.2.3 Generate coordinated release plans across packages

Release Branch Workflows

Git Flow

main (production) ← release/1.2.0 ← develop ← feature/login ← hotfix/critical-fix

Advantages: Clear separation of concerns Stable main branch Parallel feature development Structured release process

Process: Create release branch from develop: git checkout -b release/1.2.0 develop Finalize release (version bump, changelog) Merge to main and develop Tag release: git tag v1.2.0 Deploy from main

Trunk-based Development

main ← feature/login (short-lived) ← feature/payment (short-lived) ← hotfix/critical-fix

Advantages: Simplified workflow Faster integration Reduced merge conflicts Continuous integration friendly

Process: Short-lived feature branches (1-3 days) Frequent commits to main Feature flags for incomplete features Automated testing gates Deploy from main with feature toggles

GitHub Flow

main ← feature/login ← hotfix/critical-fix

Advantages: Simple and lightweight Fast deployment cycle Good for web applications Minimal overhead

Process: Create feature branch from main Regular commits and pushes Open pull request when ready Deploy from feature branch for testing Merge to main and deploy

Feature Flag Integration

Feature flags enable safe, progressive rollouts:

Types of Feature Flags

Release flags: Control feature visibility in production Experiment flags: A/B testing and gradual rollouts Operational flags: Circuit breakers and performance toggles Permission flags: Role-based feature access

Implementation Strategy

Progressive rollout example

if feature_flag("new_payment_flow", user_id): return new_payment_processor.process(payment) else: return legacy_payment_processor.process(payment)

Release Coordination

Deploy code with feature behind flag (disabled) Gradually enable for percentage of users Monitor metrics and error rates Full rollout or quick rollback based on data Remove flag in subsequent release

Release Readiness Checklists

Pre-Release Validation

[ ] All planned features implemented and tested