Define release/versioning strategy #71
Description
Problem
We have no versioning or release strategy. The changelog is organized by logical feature rather than versions, and there's no tagging, semver, or release cadence defined.
Spec
Define and document:
- Versioning scheme (semver, calver, or other)
- What constitutes a release vs a commit to main
- How the changelog maps to versions
- Whether to use GitHub Releases, git tags, or both
- Git tags on source code (e.g.
v0.0.1) pointing to the merge commit for each release - Automation: auto-generate release notes from PRs/commits, or manual
- How this interacts with
uvpackaging (pyproject.tomlversion field)
Initial version assignments
| Version | Scope | Date | Tag target |
|---|---|---|---|
| v0.0.1 | Original copilot-usage CLI tool (PR #1) | 2026-03-13 | Merge commit of PR #1 |
| v0.0.2 | Initial gh-aw workflows + agent-driven bug fixes (PRs #6, #9, #11, #15, #28, #33, #37, #40, #41, #42) | 2026-03-13 | Last merge commit of the batch |
| v0.0.3 | Autonomous agent pipeline — ci-fixer, review-responder, quality-gate, implementer upgrades, repo settings (PRs #45, #46, #49, #50, #51, #57, #64, #65, and related config) | 2026-03-14–15 | Last merge commit once pipeline work completes |
The changelog should be restructured to group entries under version headers once this is implemented.