home / skills / wdm0006 / python-skills / release-management

release-management skill

/skills/release-management

This skill helps manage Python library releases with semantic versioning, changelog maintenance, and automated GitHub Actions pipelines.

npx playbooks add skill wdm0006/python-skills --skill release-management

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
3.0 KB
---
name: managing-python-releases
description: Manages Python library releases including semantic versioning, changelog maintenance (Keep a Changelog format), release automation with GitHub Actions, and deprecation workflows. Use when planning releases, writing changelogs, automating release pipelines, or communicating breaking changes.
---

# Python Release Management

## Semantic Versioning

```
MAJOR.MINOR.PATCH (e.g., 1.2.3)

PATCH: Bug fixes, no API changes
MINOR: New features, backward compatible
MAJOR: Breaking changes
```

## Changelog Format (Keep a Changelog)

```markdown
# Changelog

## [Unreleased]
### Added
- New `batch_encode()` function

## [1.2.0] - 2024-03-15
### Added
- Support for custom formats (#123)

### Fixed
- Edge case at -180 longitude (#145)

### Deprecated
- `old_function()` - use `new_function()` instead

[Unreleased]: https://github.com/user/repo/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/user/repo/releases/tag/v1.2.0
```

**Categories:** Added, Changed, Deprecated, Removed, Fixed, Security

## Version in Code

```python
# src/package/__init__.py
__version__ = "1.2.3"

# Or use importlib.metadata
from importlib.metadata import version
__version__ = version("my-package")
```

## GitHub Actions Release

```yaml
# .github/workflows/release.yml
on:
  push:
    tags: ['v*']

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
      - run: pip install build && python -m build
      - uses: softprops/action-gh-release@v1
        with:
          files: dist/*
      - uses: pypa/gh-action-pypi-publish@release/v1
```

## Deprecation Process

```python
import warnings

def old_function():
    """Deprecated: Use new_function() instead."""
    warnings.warn(
        "old_function() deprecated, will be removed in 2.0.0",
        DeprecationWarning,
        stacklevel=2,
    )
    return new_function()
```

## Release Process

```bash
# 1. Update CHANGELOG.md (move Unreleased to version)
# 2. Bump version in pyproject.toml and __init__.py
# 3. Commit and tag
git commit -am "Release v1.2.0"
git tag -a v1.2.0 -m "Release v1.2.0"
git push origin main --tags
# 4. CI publishes automatically
```

For detailed workflows, see:
- **[AUTOMATION.md](AUTOMATION.md)** - Version bump scripts
- **[MIGRATION.md](MIGRATION.md)** - Migration guide template

## Checklist

```
Before Release:
- [ ] All tests pass
- [ ] CHANGELOG updated
- [ ] Version bumped
- [ ] Documentation current

After Release:
- [ ] PyPI shows new version
- [ ] pip install works
- [ ] GitHub release created
- [ ] Docs updated
```

## Learn More

This skill is based on the [Maintenance](https://mcginniscommawill.com/guides/python-library-development/#maintenance-the-long-game) section of the [Guide to Developing High-Quality Python Libraries](https://mcginniscommawill.com/guides/python-library-development/) by [Will McGinnis](https://mcginniscommawill.com/).

Overview

This skill manages Python library releases end-to-end: semantic versioning, Keep a Changelog–style changelogs, GitHub Actions release automation, and deprecation workflows. It provides concrete steps and templates to prepare, publish, and communicate releases reliably. Use it to standardize release cadence, avoid accidental breaking changes, and automate packaging and PyPI publishing.

How this skill works

The skill inspects and updates version metadata in code (e.g., __version__ or importlib.metadata), helps maintain a Keep a Changelog formatted CHANGELOG.md, and generates or validates release commits and tags. It includes GitHub Actions workflow templates that trigger on tags to build distributions, publish GitHub releases, and push packages to PyPI. It also provides a deprecation pattern that emits DeprecationWarning with a removal target version to guide users toward replacements.

When to use it

  • Preparing a new release and writing the changelog entry
  • Automating releases via CI/CD when pushing version tags
  • Planning and communicating breaking changes or deprecations
  • Ensuring version in code and package metadata are consistent
  • Validating release checklist before publishing

Best practices

  • Follow semantic versioning: patch for fixes, minor for compatible features, major for breaking changes
  • Keep a single source of truth for version (module __version__ or importlib.metadata) and update pyproject.toml consistently
  • Use Keep a Changelog categories (Added, Changed, Deprecated, Removed, Fixed, Security) and keep an Unreleased section
  • Automate publishing with GitHub Actions that run on tag push; require tests and build steps before publishing
  • Mark deprecated APIs with DeprecationWarning including the version they will be removed and link to migration guidance

Example use cases

  • Write the Unreleased changelog section for a minor feature and move it to a versioned entry when cutting the release
  • Bump __version__ in the package, tag vX.Y.Z, and let GitHub Actions build and publish wheels and sdist to PyPI
  • Add a deprecation warning to an old function and list it under Deprecated in the changelog with a recommended replacement
  • Use the release checklist to gate releases: tests, docs, changelog, version bump, and successful CI publish
  • Create a release workflow that uploads artifacts to a GitHub Release and then publishes to PyPI automatically

FAQ

How should I choose whether to bump major, minor, or patch?

Bump patch for bug fixes with no API change, minor for new backward-compatible features, and major for breaking changes that require user action or code changes.

Where should the canonical version live?

Keep a single canonical source: a package __init__.py __version__ or use importlib.metadata. Ensure pyproject.toml and build metadata reflect the same value to avoid mismatches.