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.