Release Manager

Release Manager is a community skill for automating software release processes, covering version management, changelog generation, release branching, artifact publishing, and deployment coordination for reliable software delivery.

What Is This?

Overview

Release Manager provides tools for automating and standardizing software release workflows. It covers version management that applies semantic versioning rules to determine version bumps based on commit history and change types, changelog generation that creates formatted release notes from conventional commits and pull request descriptions, release branching that manages branch creation, cherry-picking, and merge strategies for release preparation, artifact publishing that builds and publishes packages to registries like npm, PyPI, and Docker Hub, and deployment coordination that sequences release steps across staging and production environments. The skill standardizes release workflows.

Who Should Use This

This skill serves engineering teams managing frequent software releases, DevOps engineers automating deployment pipelines, and project maintainers publishing open source packages to public registries.

Why Use It?

Problems It Solves

Manual version numbering leads to inconsistent versions that do not accurately reflect the scope of changes. Writing changelogs by hand is tedious and results in incomplete or delayed release notes. Release branching and cherry-picking without clear processes introduces bugs when wrong commits are included or excluded. Publishing artifacts to multiple registries requires coordinated steps that are error-prone when performed manually.

Core Highlights

Version calculator determines the next version from commit history and change types. Changelog builder generates formatted release notes from commits and pull requests. Branch manager handles release branch creation and cherry-pick operations. Artifact publisher builds and pushes packages to configured registries.

How to Use It?

Basic Usage

import subprocess
import re
from datetime import date

def get_version() -> str:
  tags = subprocess.run(
    ['git', 'tag',
      '--sort=-v:refname'],
    capture_output=True,
    text=True)
  lines = tags.stdout\
    .strip().split('\n')
  return lines[0] if (
    lines[0]) else '0.0.0'

def bump_version(
  current: str,
  bump: str
) -> str:
  m = re.match(
    r'v?(\d+)\.(\d+)'
    r'\.(\d+)', current)
  major, minor, patch = (
    int(m.group(1)),
    int(m.group(2)),
    int(m.group(3)))
  if bump == 'major':
    return (
      f'{major+1}.0.0')
  if bump == 'minor':
    return (
      f'{major}.{minor+1}.0')
  return (
    f'{major}.{minor}'
    f'.{patch+1}')

def changelog(
  from_tag: str
) -> str:
  log = subprocess.run(
    ['git', 'log',
      f'{from_tag}..HEAD',
      '--format=%s'],
    capture_output=True,
    text=True)
  lines = log.stdout\
    .strip().split('\n')
  today = date.today()\
    .isoformat()
  entries = '\n'.join(
    f'- {l}' for l
    in lines if l)
  return (
    f'## {today}\n'
    f'{entries}')

current = get_version()
new_ver = bump_version(
  current, 'minor')
notes = changelog(current)
print(f'Release {new_ver}')
print(notes)

Real-World Examples

import subprocess
import json

class ReleaseManager:
  def __init__(
    self,
    repo_path: str
  ):
    self.path = repo_path

  def run(self, cmd):
    return subprocess.run(
      cmd, cwd=self.path,
      capture_output=True,
      text=True, check=True)

  def create_branch(
    self, version: str
  ):
    branch = (
      f'release/{version}')
    self.run(['git',
      'checkout', '-b',
      branch])
    return branch

  def tag(
    self, version: str,
    message: str
  ):
    self.run(['git',
      'tag', '-a',
      f'v{version}',
      '-m', message])

  def publish_npm(self):
    self.run(
      ['npm', 'publish'])

  def release(
    self,
    version: str,
    notes: str
  ):
    branch = (
      self.create_branch(
        version))
    self.tag(
      version, notes)
    self.publish_npm()
    return {
      'version': version,
      'branch': branch}

Advanced Tips

Use conventional commit messages to automate version bump decisions based on commit types like feat, fix, and breaking changes. Create release candidates on separate branches to allow testing before final release tagging. Automate changelog formatting with categories for features, fixes, and breaking changes.

When to Use It?

Use Cases

Automate semantic version bumps based on conventional commits in a continuous delivery pipeline. Generate formatted changelogs from pull request descriptions for each release. Publish npm packages with automated version tagging and registry upload.

Related Topics

Release management, semantic versioning, changelog generation, CI/CD, package publishing, and deployment automation.

Important Notes

Requirements

Git repository with tagged releases for version history tracking. Conventional commit format or structured PR descriptions for automated changelog generation. Registry credentials for publishing packages to npm, PyPI, or container registries.

Usage Recommendations

Do: follow semantic versioning strictly to communicate the scope of changes to consumers. Test release branches in staging before tagging final releases. Automate the entire release process to reduce human error in multi-step workflows.

Don't: manually edit version numbers when automated tooling can determine the correct bump from commit history. Skip changelog generation since users and teams depend on release notes. Force push release tags after they have been published since consumers may have already referenced them.

Limitations

Automated version bumping requires consistent commit message conventions that all contributors follow. Changelog quality depends on the descriptiveness of commit messages and pull request titles. Multi-registry publishing requires separate credentials and configuration for each target platform.