Release Process
This document describes the release process for the UniFi MCP Server.
Overview
Releases are published through GitHub Actions with optional manual steps for package registries. The process is intentionally lightweight so it can support frequent patch releases and larger roadmap milestones.
Release workflow
1. Tag the release
Create and push a semantic version tag for the version you are shipping:
Tagging rules:
- Use semantic versioning:
vMAJOR.MINOR.PATCH
- Prefix every tag with
v
- Match the tag to the version recorded in
pyproject.toml and the release notes
2. GitHub Actions validation
After the tag is pushed, the release workflow should:
- Run the full test suite
- Run the security scans
- Build multi-arch Docker images
- Publish container images to GitHub Container Registry
- Create the GitHub release entry
- Publish the wheel and sdist to PyPI using the repository’s trusted publisher
- Generate or attach release notes
3. Manual publishing steps
The release workflow publishes the Python package and container images after
the blocking test and security gates pass. Do not upload a second copy from a
workstation.
PyPI
PyPI publication is performed by pypa/gh-action-pypi-publish with the
repository Actions secret PYPI_RELEASE_KEY, whose value is maintained in the
Bitwarden secrets project. The workflow uses the PyPI token as __token__ and
publishes only after the build-and-test job succeeds. If PyPI trusted
publishing is configured later, replace the token inputs with OIDC and remove
the secret after verifying the new publisher claims.
Docker images
MCP Registry
Pre-release checklist
Code quality
Security
Documentation
Verification
Post-release verification
After publishing, verify the release artifacts:
- Pull the tagged Docker image and confirm the server starts
- Install the published Python package and confirm the reported version
- Confirm the GitHub release points at the expected commit/tag
- Confirm the release notes describe the shipped changes accurately
Rollback procedures
If a bad release is published:
- Delete or retag only if the release has not been broadly consumed
- Yank the PyPI package if necessary
- Deprecate or retract the Docker tag if the registry workflow allows it
- Publish a patch release with the fix and clear notes
Notes
- Keep release steps simple and repeatable.
- Do not hardcode old version numbers into new releases.
- Treat documentation sync as part of release readiness, not an afterthought.
Last modified on November 8, 2026