Release Process (Towncrier)
Relevant source files
The following files were used as context for generating this wiki page:
The Infrahub MCP release process manages versioning and changelog assembly using Towncrier. It replaces the previous release-drafter system with a workflow based on news fragments, label-driven version bumping, and reviewable release Pull Requests (PRs).
This process ensures that every change is documented by its contributor and that release notes are complete and auditable before a tag is created. The project follows a single long-lived branch model using stable, and versions are never bumped directly on this branch.
Sources: specs/003-towncrier-release-process/spec.md:6-14, specs/003-towncrier-release-process/plan.md:12-25, AGENTS.md:52-59
News Fragments
A news fragment is a small Markdown file created for every pull request that changes behavior. These fragments prevent merge conflicts in CHANGELOG.md by allowing contributors to write their entries in separate files.
Fragment Types
The system supports seven standard fragment types, each corresponding to a section in the final changelog:
| Type | Directory | Description |
|---|---|---|
security | changelog/security | Security-related changes or fixes |
removed | changelog/removed | Removed features or components |
deprecated | changelog/deprecated | Features marked for future removal |
added | changelog/added | New features or functionality |
changed | changelog/changed | Changes to existing behavior |
fixed | changelog/fixed | Bug fixes |
housekeeping | changelog/housekeeping | Internal, tooling, or documentation work |
Sources: pyproject.toml:161-197, AGENTS.md:47-50
Creating Fragments
Contributors create fragments using the following command format:
uv run towncrier create -c "Description of change" <issue_or_slug>.<type>.md
If no issue number exists, you must use a descriptive slug prefixed with +, such as +feature-name.added.md.
Sources: AGENTS.md:46-47, pyproject.toml:159-160
Validation and Gates
Continuous Integration (CI) enforces the fragment requirement:
- PR Check:
changelog-check.ymlfails a PR if it adds no file underchangelog/and lacks theci/skip-changeloglabel. - Actionable Feedback: Failure messages provide the exact
towncrier createcommand and list available types. - Escape Hatch: Trivial PRs (e.g., typo fixes) can bypass the check by applying the
ci/skip-changeloglabel.
Sources: specs/003-towncrier-release-process/tasks.md:32-37, specs/003-towncrier-release-process/spec.md:54-58
Release Preparation Workflow
The release preparation is triggered via the Auto bump version GitHub Action. This workflow automates version calculation and changelog assembly.
Version Calculation
The system calculates the next version based on PR labels:
changes/major: Major version bump.changes/minor: Minor version bump.changes/patch: Patch version bump.
Sources: specs/003-towncrier-release-process/spec.md:35-42, specs/003-towncrier-release-process/plan.md:33-35
Automated Assembly Flow
When the release workflow runs, it performs the following steps:
The diagram shows the sequence from triggering the workflow to the final publication.
Sources: specs/003-towncrier-release-process/tasks.md:42-63, specs/003-towncrier-release-process/spec.md:89-100
Synchronized Files
The release process ensures that all version-carrying files are updated simultaneously:
pyproject.toml: Updated viasync-versions.sh.server.json: Updated viasync-versions.sh(top-level and package versions).CAPABILITIES.md: Regenerated viaupdate-capabilities.shto ensure the version in the H2 heading (## Infrahub MCP Server <version>) matches the code.CHANGELOG.md: Updated by inserting the Towncrier-rendered section after the<!-- towncrier release notes start -->marker.
Sources: specs/003-towncrier-release-process/spec.md:79-87, pyproject.toml:155-158
Publication
A release is published only when the chore(release): vX.Y.Z PR is merged into stable.
- Tagging: Merging the PR triggers the
release-publish.ymlworkflow, which creates av-prefixed git tag. - Release Body: The GitHub Release body is populated using the Towncrier-rendered section extracted from the PR.
- Auditability: The extracted body must mention the version being released; the workflow fails if the body is empty or incorrect.
- Decoupling: The decision to publish is based on whether a tag already exists for the current
pyproject.tomlversion, ensuring that squash, rebase, and merge operations behave identically.
Sources: specs/003-towncrier-release-process/tasks.md:54-63, specs/003-towncrier-release-process/spec.md:47-52
Summary
The Towncrier-based release process provides a structured way to handle distributed changelog entries. By enforcing fragment creation at the PR level and using automated workflows for versioning and assembly, the project maintains a reliable and human-readable audit trail of all changes. The use of a reviewable release PR serves as a final quality gate before any code is tagged or published to PyPI and the MCP registry.
Sources: specs/003-towncrier-release-process/spec.md:16-25, specs/003-towncrier-release-process/plan.md:12-16