release

name	release
description	Release a new version of outport. Use when the user says "release", "let's release", "tag a release", "ship it", "cut a release", "push a new version", or asks about the release process. Also use when the user asks to deploy docs after a release.

Release

Guides the release of a new outport version. Runs pre-flight checks, determines the version, tags, and deploys docs.

Step 1 — Pre-flight

Verify master is clean and ready:

git checkout master
git pull

Check for uncommitted changes. If the working tree is dirty, stop and ask.

Run tests and lint:

just test
just lint

Both must pass before proceeding. If tests fail, stop and fix.

Step 2 — Determine version

Check the latest tag:

git tag --sort=-v:refname | head -5

Look at what's changed since the last release:

git log --oneline $(git tag --sort=-v:refname | head -1)..HEAD

Suggest the next version based on what changed:

• Patch (v0.X.Y+1): bug fixes only
• Minor (v0.X+1.0): new features, non-breaking changes
• Major: breaking changes (rare pre-1.0 — minor bumps are fine for breaking changes while pre-1.0)

Present the suggestion with the commit list and ask the user to confirm the version number before proceeding.

Step 3 — Tag and push

git tag vX.Y.Z
git push origin vX.Y.Z

This triggers the GitHub Actions release workflow which builds binaries and updates the Homebrew tap.

Step 4 — Deploy docs

Check if any docs changed since the last release:

git diff --name-only $(git tag --sort=-v:refname | head -2 | tail -1)..HEAD -- docs/ README.md

If docs changed, build and deploy:

npx vitepress build docs
npx wrangler pages deploy docs/.vitepress/dist --project-name outport-dev

If no docs changed, skip this step and say so.

Step 5 — Verify

Check the GitHub Actions run:

gh run list --limit 3

If the latest run is still in progress, let the user know and suggest they check back. If it completed, report the status.

Tell the user to verify the install when ready:

brew update && brew upgrade outport && outport --version