feat: add automated versioning and release process

[GoodbyePlanet]

Closes #111

The repo had zero tags, zero GitHub releases and no changelog, so the serverInfo.version clients read from importlib.metadata mapped to no commit anyone could check out. This adds the release process.

What a release looks like now

release-please watches main, opens a chore(main): release X.Y.Z PR that bumps pyproject.toml and writes CHANGELOG.md from Conventional Commit messages. Merging that PR tags the commit vX.Y.Z and cuts a GitHub Release. Nothing ships until a human merges it.

A release produces a GitHub Release with source and changelog only — no PyPI, no image. Pushing ghcr.io/goodbyeplanet/semcode:X.Y.Z is the one with real user-facing value and is left as a follow-up, per the issue.

File	Purpose
.github/workflows/release.yml	release-please-action@v4 on push to main, contents:write + pull-requests:write, concurrency-guarded
release-please-config.json	release-type: python, package semcode, explicit changelog-sections
.release-please-manifest.json	seeded {".": "1.1.0"} so the first automated bump is 1.2.0, not 0.1.0
CHANGELOG.md	hand-reconstructed 0.1.0 / 1.0.0 / 1.1.0
.github/dependabot.yml	commit prefix chore(deps) → deps
README.md, .claude/CLAUDE.md	the contract

Decisions taken

Dependabot prefix changed to deps. The issue asked whether chore(deps): should warrant a release. It should — weeks of Dependabot merges otherwise produce no release boundary. But changelog-sections only controls changelog display, not version bumping, and a chore-typed commit won't reliably surface. Switching the prefix makes "deps → patch bump, listed under Dependencies" deterministic. Existing chore(deps) commits are all pre-tag, so nothing is lost.

Changelog reconstructed from the full history, not seeded with a stub. Version boundaries came from pyproject.toml itself: 0.1.0 at init (2026-04-23), 1.0.0 at the rename to semcode (d2d2c50), 1.1.0 at d8c0f1c. All 70 referenced SHAs resolve. Entries from 1.2.0 onward are generated; the reconstructed ones are documented as frozen.

Squash-merge titles: no settings change needed. The issue flagged this, but it only bites under squash-merging. This repo merge-commits, so the branch's real commits stay on main and release-please reads those; Merge pull request #NNN subjects have no Conventional Commit type and are skipped. The inverse applies instead — every branch commit becomes a changelog line, so keep branch commits release-worthy or squash locally. Also: don't repeat 780b670 feat: Merge conflicts — a hand-labelled merge commit like that would count as a minor bump.

Tags — needs a push

Created locally, not pushed, since pushing tags is irreversible:

git push origin v0.1.0 v1.0.0 v1.1.0

• v0.1.0 → d085d6d
• v1.0.0 → d2d2c50
• v1.1.0 → 0f9af33 (current main, not d8c0f1c)

v1.1.0 sits on current main because five commits — including the full-text-index perf work and the recall fix — shipped under that version number after the bump. It also gives release-please its commit boundary, so the first generated changelog covers only new work rather than rescanning all 181 commits. The three tags together make every compare/ link in CHANGELOG.md resolve.

Verification

uvx ruff format --check . clean, uvx ruff check . clean, 330 tests pass. JSON and YAML parse; every changelog SHA resolves. The release workflow itself can't be exercised until this is on main.

🤖 Generated with Claude Code