Skip to main content

release-automation

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.

Quellinformationen

Repository
NVIDIA/multi-storage-client
Letzte Quellaktivität
9. September 2026 um 18:30
Erkannte Sprache von SKILL.md
Englisch
Sterne
87
Forks
28

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

Datei-Explorer
2 Dateien

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
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)
Auf GitHub ansehen