- name
- release-automation
- description
- Prepares and automates the release process for multi-storage-client (version bump, release notes, checklist). Use when the user wants to cut a release, bump version, prepare release, publish a new version, or automate release steps.
# Release Automation
Guides the agent through preparing a release for the multi-storage-client repository. Tagging is done by the pipeline after the release MR is merged; this skill covers only the in-repo changes (version bump, release notes). Do not ask the user to run `git tag` or push a tag.
## When to Use
- User asks to "cut a release", "bump version", "prepare release", "publish new version", or "automate release".
- User wants to move unreleased notes into a versioned file and bump the package version.
## Prerequisites
- Work from repository root.
- Ensure `.release_notes/.unreleased.md` has been updated with notable changes (per PR template). If empty or placeholder-only, confirm with the user before releasing.
## Release Preparation Workflow
### 1. Determine the new version
- Read current version from `multi-storage-client/pyproject.toml` (`version = "X.Y.Z"`).
- If the user specified a version (e.g. "0.44.0"), use it. Otherwise propose:
- **Patch** (e.g. 0.43.0 → 0.43.1): bug fixes only.
- **Minor** (e.g. 0.43.0 → 0.44.0): new features, backward-compatible.
- **Major**: breaking changes (rare; confirm with user).
### 2. Bump package version
- In `multi-storage-client/pyproject.toml`, set `version = "<new_version>"` (e.g. `"0.44.0"`).
### 3. Finalize release notes
- Read `.release_notes/.unreleased.md`.
- Read git history for changes since the last release: `git log <previous_version>..HEAD --no-merges --format='%h %s%n%b'` (tags are unprefixed, e.g. `0.42.0` not `v0.42.0`). Use this to find and add relevant entries; omit CI/CD, build, and chore-only commits.
- Create `.release_notes/<new_version>.md` with that content (e.g. `.release_notes/0.44.0.md`). Preserve structure (Breaking Changes, New Features, Bug Fixes, etc.).
- Skip mentioning any changes that are CI/CD related.
- Reset `.release_notes/.unreleased.md` to its template (with `<!-- Add items here. -->` at the top). If unsure whether the repo convention expects a reset, ask the user before modifying.
### 4. Verification (recommended)
- Run `just build` from repo root (runs analyze, unit tests, ray tests; in CI also runs package).
### 5. Handoff checklist
Present a short checklist for the user:
- [ ] Version bumped in `multi-storage-client/pyproject.toml`.
- [ ] `.release_notes/<new_version>.md` created; `.release_notes/.unreleased.md` handled as above.
- [ ] `just build` passed (or user will run locally).
- [ ] Create a git commit with the release changes and open/merge an MR; the pipeline will create and push the tag after merge.
## Reference
- Repo-specific paths and CI details: [reference.md](reference.md)
Ver en GitHub