release

# Release process for lading

## 1. Determine the next version

- Read `lading/Cargo.toml` and `CHANGELOG.md` to find the current version and unreleased changes.
- If the user hasn't specified a version, suggest one based on semver:
  - Breaking changes in the unreleased section -> bump minor (we're pre-1.0).
  - Otherwise bump patch.
- Confirm the version with the user before proceeding.

## 2. Create a release branch

- Create a branch from main: `git checkout -b prepare-release-v<version>`

## 3. Update CHANGELOG.md

- Read `CHANGELOG.md`.
- Insert a new `## Unreleased` header (with empty subsections) above the current unreleased content.
- Rename the existing unreleased content block to `## [<version>]`.
- Ensure there is a blank line between the new empty `## Unreleased` and `## [<version>]`.

## 4. Bump version in Cargo.toml

- Edit `lading/Cargo.toml` to set `version = "<new_version>"`.

## 5. Update Cargo.lock

- Run `cargo check` to propagate the version change into the lockfile without re-resolving all dependencies.

## 6. Commit and create PR

- Stage `CHANGELOG.md`, `lading/Cargo.toml`, and `Cargo.lock`.
- Commit with message: `release: v<version>`
- Push the branch and create a PR targeting main.

## 7. Tag after merge

- After the PR is merged, remind the user to tag the merge commit on main:
  - `git checkout main && git pull`
  - `git tag -a v<version> -m "v<version>"`
  - `git push origin v<version>`
- **NEVER use `git push --tags`** — always push exactly one tag at a time.
- The `release.yml` GitHub Actions workflow will automatically create a GitHub Release from the tag, pulling notes from CHANGELOG.md.