releaselisted

# Release — Version Bump, Tag, and Changelog Create a new release with a structured changelog and author attribution. ## Arguments - `<version>` — The version to release (e.g. `1.19.1`, `v2.0.0`). The `v` prefix is optional in input but always used for the git tag. If no version is given, detect the current version and suggest the next one (see Step 1). ## Workflow ### 1. Detect current version and suggest the next Read the current version and identify changes since the last tag: 1. Read the code version from `cmd/san/main.go`: ```bash grep 'var version = ' cmd/san/main.go ``` 2. Get the latest git tag: ```bash git describe --tags --abbrev=0 ``` Strip the `v` prefix for comparison. 3. **Compare.** If the code version and tag version differ, warn the user — the code may be out of sync with releases. 4. Get commits since the latest tag: ```bash git log --oneline <prev_tag>..HEAD ``` 5. **Suggest the next semver bump** based on commit content: - **Major** (`X.0.0`): commits with `BREAKING CHANGE`, or that remove/rename public APIs - **Minor** (`x.Y.0`): `feat:` commits, new functionality, new features - **Patch** (`x.y.Z`): `fix:` commits, bug fixes, docs, chores, refactors Default to **patch** if the commits don't clearly indicate otherwise. 6. **Ask the user.** Use AskUserQuestion, showing the current code version and the suggested next version: - Option 1: the suggested version (e.g. `v1.19.1` — patch) - Option 2: