Versioning & Release Process
Relevant source files
The following files were used as context for generating this wiki page:
The Versioning & Release Process manages the lifecycle of the Infrahub Skills plugin through automated changelog assembly, synchronized version updates across multiple files, and quality-gated release workflows. This system replaces the legacy release-drafter mechanism with a towncrier-managed pipeline that ensures every behavior change carries a human-written news fragment.
Sources: specs/001-towncrier-release-process/spec.md:12-19, AGENTS.md:162-171
News Fragments and Changelog Assembly
The project uses towncrier to manage the CHANGELOG.md file. Contributors must include a news fragment in every pull request that changes behavior. These fragments are small Markdown files stored in the changelog/ directory.
Fragment Requirements
A pull request check fails if a PR lacks a news fragment unless the ci/skip-changelog label is applied. Fragments are named following the pattern <issue_or_pr_number>.<type>.md. If no issue exists, a descriptive slug prefixed with + is used (e.g., +feature-name.added.md).
Sources: specs/001-towncrier-release-process/spec.md:32-42, AGENTS.md:162-168
Fragment Types
The following types are recognized by the towncrier configuration:
| Type | Directory | Description |
|---|---|---|
security | changelog/security | Security-related changes |
removed | changelog/removed | Deprecated features that have been removed |
deprecated | changelog/deprecated | Features marked for future removal |
added | changelog/added | New features or skills |
changed | changelog/changed | Changes to existing behavior |
fixed | changelog/fixed | Bug fixes |
housekeeping | changelog/housekeeping | Internal tooling, documentation, or maintenance |
Sources: pyproject.toml:79-114
Assembly Logic
During the release preparation, the Auto bump version workflow runs towncrier build. This command consumes the fragments, appends them to CHANGELOG.md under the appropriate category headings, and deletes the fragment files.
Sources: specs/001-towncrier-release-process/tasks.md:32-34, pyproject.toml:67-78
Multi-File Version Synchronization
The project version is stored in five distinct locations. All locations must remain identical to ensure consistency across the plugin marketplace, Python packaging, and skill metadata.
Version Locations
.claude-plugin/plugin.json(Canonical source).github/.release-manifest.jsonpyproject.toml- Every
skills/*/SKILL.md(in frontmatter) uv.lock
Sources: specs/001-towncrier-release-process/plan.md:27-33, AGENTS.md:183-186
Update Mechanism
The scripts/sync-versions.sh script reconciles these files. During a release, the version bump is computed from PR labels (changes/minor, changes/patch, etc.) and applied to all five locations simultaneously. The uv.lock file is specifically included in release commits to prevent stray diffs in subsequent PRs.
Sources: specs/001-towncrier-release-process/spec.md:52-56, specs/001-towncrier-release-process/tasks.md:37-43
Release Workflow
Releases are initiated through a tiered automated process that includes a reviewable pull request and quality gates.
The diagram shows the flow from merged contributions to the final published release, highlighting the quality gate at the release PR.
Sources: specs/001-towncrier-release-process/spec.md:46-65, specs/001-towncrier-release-process/tasks.md:32-50
Release Preparation
- Trigger: A maintainer dispatches the Auto bump version workflow from GitHub Actions.
- Changelog & Bump: The workflow runs
towncrier buildusing the version extracted from PR labels. - Release PR: A new pull request titled
chore(release): vX.Y.Zis opened. It contains all updated version files and the updatedCHANGELOG.md.
Sources: AGENTS.md:170-174, specs/001-towncrier-release-process/tasks.md:32-41
Quality Gates
The release PR serves as the final quality gate:
- Evaluation Suite: The
regressionpreset of the skill evaluation suite runs on the release PR. This check is mandatory and blocks the merge on failure. - Manual Review: An administrator must approve the release PR after reviewing the assembled changelog and evaluation results.
Sources: specs/001-towncrier-release-process/spec.md:58-61, specs/001-towncrier-release-process/tasks.md:65-68
Publication
Merging the release PR triggers the release-publish.yml workflow. This workflow:
- Creates a git tag (e.g.,
v1.3.0). - Publishes the GitHub Release.
- Uses the exact towncrier-rendered section for the release body.
Sources: specs/001-towncrier-release-process/tasks.md:46-50, specs/001-towncrier-release-process/plan.md:64-67
Evaluation Tiering
To manage costs while maintaining quality, evaluation runs are tiered based on the context of the change.
| Tier | Frequency | Trigger | Purpose |
|---|---|---|---|
smoke | Per PR (optional) | Manual dispatch / PR touch | Fast verification of local changes |
regression | Weekly | Scheduled | Continuous regression monitoring |
regression | Per Release | Release PR merge | Final quality gate before publication |
Sources: specs/001-towncrier-release-process/spec.md:67-72, AGENTS.md:177-181, specs/001-towncrier-release-process/tasks.md:60-68
Summary
The Versioning & Release Process ensures that the Infrahub Skills plugin maintainers can ship high-quality, documented updates. By combining news fragments with a synchronized multi-file versioning system and a blocking regression test suite, the project maintains an auditable and reliable release history. All behavior changes are explicitly recorded by contributors and verified by maintainers before reaching the default branch.