Release Process

SkillDev tools

Release process for mdvs. Use when the user asks to make a release (patch, minor, major, or release candidate).

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Release Process skill

What this skill tells your AI

The instructions your AI receives, as published by edochi/mdvs in .claude/skills/release/SKILL.md and read by ahel’s review.

Releases go through a branch + PR (because main is protected), then a tag push triggers the GitHub Actions release workflow (cargo-dist) that builds cross-platform binaries and creates a GitHub Release.

Prerequisites

Before releasing, verify:

  1. All tests pass:
cargo test
cargo clippy -- -D warnings
cargo fmt --check
  1. Main branch is clean and up to date:
git checkout main && git pull
git status  # must be clean
git log --oneline -5  # review recent commits
  1. CI is green on the latest commit:
gh run list --limit 1

Making a release

Step 1: Create release branch

git checkout -b release/v<version> main

Step 2: Bump version and changelog

Use cog bump with --skip-push (since we can't push directly to main):

cog bump --<level> --skip-push    # or --auto --skip-push

This will:

  1. Bump the version in Cargo.toml
  2. Generate/update CHANGELOG.md from conventional commits
  3. Create a bump commit
  4. Create a git tag v<new_version>

If cog bump doesn't support --skip-push, do it manually:

  1. Edit Cargo.toml version field
  2. Run cog changelog > CHANGELOG.md (or update manually)
  3. Commit: git commit -am "chore(release): v<version>"

Step 3: Push branch and create PR

git push -u origin release/v<version>
gh pr create --title "chore(release): v<version>" --body "Version bump and changelog for v<version>"

Wait for CI to pass, then merge the PR.

Step 4: Tag and push

After the PR is merged, tag main and push the tag:

git checkout main && git pull
git tag v<version>
git push origin v<version>

The tag push triggers .github/workflows/release.yml, which builds binaries for macOS, Linux, and Windows, and creates a GitHub Release.

Release levels

LevelExampleUse case
--patch0.1.0 → 0.1.1Bug fixes
--minor0.1.0 → 0.2.0New features
--major0.1.0 → 1.0.0Breaking changes
--minor --pre rc0.1.0 → 0.2.0-rc.1Release candidate
--auto(auto-detected)Let commits decide

Step 5: Monitor the release build

gh run list --limit 1                  # find the run ID
gh run watch <run-id> --exit-status    # live follow

If a build fails:

gh run view --job=<job-id> --log-failed

After success, verify the GitHub Release:

gh release view v<version>

Configuration

  • cog.toml — cocogitto config (tag prefix, bump hooks, changelog, commit validation)
  • Cargo.toml — version field, [package.metadata.dist]
  • .github/workflows/release.yml — auto-generated by dist generate, do not hand-edit

Important notes

  • publish = false — no crates.io publishing. Releases are GitHub-only for now.
  • Tag format is v{version} (e.g., v0.1.0), configured by tag_prefix = "v" in cog.toml.
  • Prerelease tags (e.g., v0.1.0-rc.1) create a GitHub Release marked as prerelease.
  • --auto reads commits since last tag: feat: → minor, fix: → patch, BREAKING CHANGE → major.
  • If cargo-dist config changes, regenerate the workflow: dist generate
  • Branch protection blocks direct pushes to main — releases always go through a PR. Tags are not blocked.

Signals

GitHub stars
27
Forks
2
Last commit
Aug 2026
Hacker News mentions
20
Advanced
Catalog kind
skill
Gateway key
release-edochi
Source
github.com/edochi/mdvs