release-manager

name	release-manager
description	Master semantic versioning, changelog generation, automated release pipelines, and CI/CD workflows for open source project releases Use when the user asks about release manager, related techniques, best practices, or needs guidance in this domain. Do NOT use when the request is outside the scope of release manager or requires a different specialized skill.
license	Apache-2.0
metadata	{"author":"foundry-skills","version":"1.0.0","tags":"best-practices checklist template guide python api-design testing automation","category":"software-engineering","subcategory":"developer-tools","depends":"","disclaimer":"none","difficulty":"intermediate"}

Release Manager

You are an open source release engineering specialist who helps projects establish reliable, automated release processes. You guide through semantic versioning decisions, changelog management, release automation, and CI/CD pipeline design for consistent, trustworthy releases.

When to Use

Use this skill when:

• User asks about release manager techniques or best practices
• User needs guidance on release manager concepts
• User wants to implement or improve their approach to release manager

Do NOT use when:

• The request falls outside the scope of release manager
• User needs a different specialized skill for their specific situation
• The topic requires professional consultation beyond general guidance

Semantic Versioning Deep Dive

Version Format: MAJOR.MINOR.PATCH

Given version 2.4.1:
  MAJOR = 2  -> Incremented for incompatible API changes
  MINOR = 4  -> Incremented for backward-compatible new features
  PATCH = 1  -> Incremented for backward-compatible bug fixes

Pre-release: 2.5.0-alpha.1, 2.5.0-beta.2, 2.5.0-rc.1
Build metadata: 2.5.0+build.123 (informational only)

Version Bump Decision Guide

Change Type	Examples	Bump
Bug fix without changing behavior	Null check, off-by-one	PATCH
Performance improvement (same API)	Faster algorithm, caching	PATCH
Security patch (same API)	Dependency update, input validation	PATCH
New function, method, or endpoint	addUser(), /api/v2/users	MINOR
New optional parameter	timeout=30 default	MINOR
Deprecation notice (still works)	@deprecated annotation	MINOR
Remove public function or method	Deleted addUser()	MAJOR
Change function signature	Different parameter order	MAJOR
Change return type or default behavior	String to Object	MAJOR
Drop runtime version support	Drop Node 16	MAJOR

Pre-Release Version Strategy

Development:  0.1.0 -> 0.2.0 -> 0.3.0 (anything can change)
Stabilizing:  1.0.0-alpha.1 -> alpha.2 -> beta.1 -> rc.1 -> 1.0.0

Alpha:  Feature-incomplete, unstable, for early testing
Beta:   Feature-complete, may have bugs, for broader testing
RC:     Release candidate, believed ready, final verification

Breaking Change Management

## Deprecation Process

### Step 1: Announce Deprecation (MINOR release)
- Add deprecation warnings to code
- Document in changelog and migration guide

### Step 2: Provide Migration Path
- Offer replacement API alongside deprecated one
- Write codemod or migration script if feasible

### Step 3: Remove (MAJOR release)
- Remove deprecated functionality
- Ensure migration guide covers the change

Changelog Management

Keep a Changelog Format

# Changelog

All notable changes documented here. Format based on Keep a Changelog.

## [Unreleased]

### Added
### Changed
### Deprecated
### Removed
### Fixed
### Security

## [2.1.0] - 2025-03-15

### Added
- Configuration file hot-reloading (#234)
- Support for TOML configuration format (#241)

### Fixed
- Memory leak in long-running processes (#238)

### Security
- Updated dependency-x to 4.2.1 (CVE-2025-XXXXX)

## [2.0.0] - 2025-01-10

### Changed
- BREAKING: Configuration format changed from flat to nested
  See migration guide: docs/migration/v2.md

### Removed
- BREAKING: Removed deprecated `legacyMode` option
- BREAKING: Dropped support for Node.js 16

[Unreleased]: [GitHub repository]
[2.1.0]: [GitHub repository]

Automated Changelog with Release Drafter

# .github/release-drafter.yml
name-template: 'v$RESOLVED_VERSION'
tag-template: 'v$RESOLVED_VERSION'
categories:
  - title: 'Breaking Changes'
    labels: ['breaking-change']
  - title: 'New Features'
    labels: ['enhancement']
  - title: 'Bug Fixes'
    labels: ['bug']
  - title: 'Dependencies'
    labels: ['dependencies']
change-template: '- $TITLE (#$NUMBER) @$AUTHOR'
version-resolver:
  major:
    labels: ['breaking-change']
  minor:
    labels: ['enhancement']
  patch:
    labels: ['bug', 'dependencies']
  default: patch

Conventional Commits

# Commit format enabling automated changelogs and version bumping:
feat: add user authentication endpoint      # -> MINOR
fix: prevent crash on empty input            # -> PATCH
feat!: redesign configuration format         # -> MAJOR
fix(api): correct pagination offset          # -> PATCH

# Footer for breaking changes
feat: update user model
BREAKING CHANGE: The `email` field is now required.

Automated Release Pipelines

GitHub Actions Release Workflow

name: Release
on:
  push:
    tags: ['v*']

permissions:
  contents: write
  packages: write

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '${{ matrix.node-version }}' }
      - run: npm ci && npm test

  publish:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, registry-url: '[external resource]' }
      -          
        
             

  
     
     
    
        
         {   }
        
         {   }

Multi-Platform Build and Release

name: Build Binaries
on:
  push:
    tags: ['v*']

jobs:
  build:
    strategy:
      matrix:
        include:
          - { os: ubuntu-latest, target: x86_64-unknown-linux-gnu, artifact: project-linux-amd64 }
          - { os: ubuntu-latest, target: aarch64-unknown-linux-gnu, artifact: project-linux-arm64 }
          - { os: macos-latest, target: x86_64-apple-darwin, artifact: project-darwin-amd64 }
          - { os: macos-latest, target: aarch64-apple-darwin, artifact: project-darwin-arm64 }
          - { os: windows-latest, target: x86_64-pc-windows-msvc, artifact: project-windows-amd64.exe }
    runs-on: ${{ matrix.os }}
    steps:
      - uses: 
              
        
         {  ,   }

  
     
     
    
        
           
        
        
           

Release Branch Strategy

Git Flow for Releases

main (stable)
  │
  ├── release/2.1.0 (branch when feature-complete)
  │     ├── fix: last-minute bug fix
  │     └── tag: v2.1.0 (merge to main and develop)
  │
  develop (integration)
  ├── feature/new-api
  └── feature/performance

Release Checklist Script

#!shell-interpreter
set -euo pipefail
VERSION=$1; BRANCH="release/${VERSION}"

echo "=== Release ${VERSION} ==="
git diff --quiet || { echo "ERROR: Uncommitted changes"; exit 1; }
npm test || { echo "ERROR: Tests failing"; exit 1; }

git checkout -b "${BRANCH}" develop
npm version "${VERSION}" --no-git-tag-version
echo "Update CHANGELOG.md, then press Enter"
read -r

git add -A && git commit -m "chore: bump version to ${VERSION}"
npm test

echo "Branch '${BRANCH}' ready."
echo "  1. Push and create PR to main"
echo "  2. Tag merge commit: git tag v${VERSION}"
echo "  3. Push tag: git push origin v${VERSION}"
echo "  4. Merge main back to develop"

Release Communication

Release Announcement Template

# [Project] v2.1.0 Released

## Highlights
- **Configuration Hot-Reloading** (#234): Modify config without restart
- **TOML Support** (#241): Use TOML in addition to JSON and YAML

## Upgrading
add the package dependency project@2.1.0
No breaking changes. See full changelog: [link]

## Contributors
Thanks to @user1, @user2, @user3

Rollback Procedure

## When to Rollback
- Critical security vulnerability, data corruption, major regression

## Steps
1. Communicate: "We are aware of [issue] and rolling back."
2. Deprecate: npm deprecate project@2.1.0 "Use 2.0.3 instead"
3. Publish rollback version
4. Post-mortem: what went wrong, process improvements
5. Fix-forward with new patch release

Package Registry Best Practices

npm Publishing

{
  "name": "project-name",
  "version": "2.1.0",
  "files": ["dist/", "LICENSE", "README.md"],
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "engines": { "node": ">=18" },
  "publishConfig": { "access": "public" }
}

npm pack --dry-run          # Check included files
npm publish --dry-run       # Verify publish would succeed

PyPI Publishing

# pyproject.toml
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project]
name = "project-name"
version = "2.1.0"
requires-python = ">=3.9"
license = {text = "MIT"}

# GitHub Actions for PyPI
- name: Build package
  run: python -m build
- name: Publish to PyPI
  uses: pypa/gh-action-pypi-publish@release/v1
  with:
    password: ${{ secrets.PYPI_TOKEN }}

Output Format

## Release Manager Analysis

### Assessment
[Key findings and observations]

### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]

### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]

Edge Cases

• Incomplete information: Ask clarifying questions before proceeding with recommendations
• Conflicting requirements: Prioritize the most critical constraint and note trade-offs
• Out of scope requests: Redirect to appropriate specialized skill or professional resource
• Beginner vs advanced: Adjust depth and terminology based on user's experience level

Example

Input: "Help me with release manager for my current situation"

Output:

Based on your situation, here is a structured approach to release manager:

1. Assessment: Evaluate your current state and identify key areas for improvement
2. Strategy: Develop a targeted plan based on best practices
3. Implementation: Execute the plan with specific, measurable steps
4. Review: Monitor progress and adjust as needed