Power Release

Create a Git Flow release branch with version bumping, changelog generation, and pre-release checks.

When to Use This Command

Run this command when you need to:

• Cut a release branch from develop to stabilize code before deploying to production
• Bump version numbers across package files, update changelogs, and prepare release notes
• Run comprehensive pre-release validation including tests, linting, and build verification

Consider alternatives when:

• You use continuous deployment and ship every commit on main without formal release branches
• You need to create a patch release which should use the hotfix workflow instead

Quick Start

Configuration

Copy
name: power-release
type: command
category: git

Example Invocation

Copy
claude command:run power-release --version "2.5.0"

Example Output

Creating release branch...
  Current version: 2.4.3
  Target version: 2.5.0
  Commits since v2.4.3: 23

Branch: release/2.5.0
  Base: develop (commit c91d8f2)
  Tracking: origin/release/2.5.0

Version bump:
  package.json: 2.4.3 -> 2.5.0
  build.gradle: 2.4.3 -> 2.5.0

Changelog generated:
  12 features, 8 fixes, 3 chores added to CHANGELOG.md

Pre-release checks: All passing
  Tests: 284 passed, 0 failed
  Lint: 0 errors, 0 warnings
  Build: success (42s)

Core Concepts

Release Process Overview

Aspect	Details
Source	Branches from develop when features for the release are complete
Version	Follows semantic versioning with major.minor.patch format
Changelog	Auto-generated from conventional commit messages since last release
Validation	Runs full test suite, linter, and production build before proceeding
Freeze	Only bug fixes are allowed on the release branch, no new features

Release Workflow

develop:  --*--*--*--*--*--------*--*-->
                       |        /
release:               *--fix--*
                       |        \
main:     --*----------+---------*-[v2.5.0]-->
           v2.4.3      branch    merge+tag

Configuration

Parameter	Type	Default	Description
version	string	(required)	Target version number following semver format
bump-files	string[]	auto-detect	List of files containing version numbers to update
changelog	boolean	true	Auto-generate changelog from commit history
run-checks	boolean	true	Run tests, lint, and build before creating release
draft-notes	boolean	true	Create draft GitHub release notes automatically

Best Practices

1. Freeze feature development - Once the release branch is cut only bug fixes should go into it. New features must target the next release by merging into develop instead.

2. Use conventional commits - Consistent commit message formats like feat:, fix:, and chore: enable accurate automatic changelog generation that saves hours of manual documentation work.

3. Test on release branch specifically - Do not assume passing tests on develop means the release is stable. Dependencies, environment variables, and build configs may differ on the release branch.

4. Coordinate with QA early - Notify your QA team when the release branch is cut so they can begin testing immediately. The release branch is their stable target for validation.

5. Keep the release branch short-lived - A release branch that lingers for weeks accumulates drift from develop. Aim to stabilize and finish within a few days at most.

Common Issues

1. Version conflict in package files - If multiple package files have different versions the command flags the inconsistency. Align them manually before retrying the release creation.

2. Changelog includes commits from previous release - This happens when tags are missing or misplaced. Verify that the previous release tag exists on the correct commit in the history.

3. Build fails on release branch but passes on develop - Release branches sometimes expose environment-specific issues. Check for hardcoded paths, missing env variables, or dev-only dependencies that are present in the develop environment but not in the release build pipeline.

4. Changelog categories are wrong - If commits use non-standard prefixes like add: instead of feat:, the changelog generator may miscategorize them. Standardize commit message prefixes across the team and configure the changelog parser to recognize your project's specific conventions.