Rustfs Release Version Bump

RustFS Release Version Bump

Use this skill to prepare and verify release version files. Commit, push, and PR steps apply only when included in the user's delivery scope; publishing release tags belongs to rustfs-release-publish.

Validated baseline: release pattern used in PR #2957.

Required inputs

• Exact target version, for example 1.0.0-beta.4.
• Delivery scope: local (edit/verify), git (commit/push), or GitHub (commit/push/PR). Derive it from the conversation; when unspecified, prepare and verify locally without blocking on a delivery question.

If target version is missing or ambiguous, stop and ask before editing.

Reject any target version containing -preview: preview identifiers are tag-only (see rustfs-release-publish) and must never be written into version files. If asked for one, stop and point to the release pipeline instead of editing.

Read before editing

• AGENTS.md (root and nearest path-specific files).
• .github/pull_request_template.md only when preparing a PR.
• Current branch status and diff against origin/main.

Default release file scope

Treat the following file list as the default checklist for each release bump:

• Cargo.toml
• Cargo.lock
• README.md
• README_ZH.md
• flake.nix
• helm/rustfs/Chart.yaml
• rustfs.spec

Only drop a file when the current repository release process clearly no longer requires it.

Hard release policy

• Docker doc tags use <version> (for example rustfs/rustfs:1.0.0-beta.4), not v<version>.
• Helm chart version mapping follows beta.N -> 0.N.0.
• rustfs.spec Release uses prerelease suffix only (for example beta.4).
• Do not change these rules without explicit confirmation.

Step-by-step workflow

1. Confirm intent and isolate scope

• Use the exact target and delivery scope already supplied; ask only for a missing or ambiguous target or a material release-policy choice.
• Inspect current branch and ensure only release-related files are touched for this task.

2. Update workspace versions

• Bump [workspace.package].version in Cargo.toml.
• Bump internal workspace crate dependency versions in Cargo.toml.
• Update Cargo.lock so workspace package versions match target version.
• Re-scan for partial leftovers.

3. Update release assets

• README.md and README_ZH.md: update versioned Docker examples to target version.
• flake.nix: update package version to target version.
• helm/rustfs/Chart.yaml:
• appVersion = target version.
• version follows chart mapping rule, for example:
• 1.0.0-beta.3 -> 0.3.0
• 1.0.0-beta.4 -> 0.4.0
• rustfs.spec:
• Set Release to prerelease suffix (example beta.4).
• Add/update top changelog entry with exact format:
• * Thu May 20 2026 houseme <housemecn@gmail.com>
• - Update RPM package to RustFS 1.0.0-beta.4
• Changelog identity and time must come from current environment:
• git config --get user.name
• git config --get user.email
• date '+%a %b %d %Y'
• Changelog version text must match target release version exactly.

4. Verify before shipping

• Run:
• make pre-commit
• If make pre-commit fails, fix task-attributable failures and rerun affected checks. Report unresolved required checks as BLOCKED; do not silently widen scope to fix unrelated issues.

5. Commit strategy (only when committing is authorized)

• Preferred split when both parts changed:
• chore(release): prepare <version> for Cargo.toml and Cargo.lock.
• chore(release): align release assets for <version> for docs and packaging files.
• If user asks for one commit, use one commit.
• Stage only intended release files; do not include unrelated working tree changes.

6. Push and PR (only for the authorized delivery scope)

• Push branch:
• Use the user-requested or configured push remote: git push -u <push-remote> <branch> (first push), or git push when tracking is already configured.
• Create PR with template headings unchanged:
• gh pr create --base main --head <branch> --title ... --body-file ...
• PR title/body must be English.
• Use N/A for non-applicable template sections.
• Include verification commands and any BLOCKED reason clearly.

Recommended check commands

• git status --short --branch
• git diff --name-only origin/main...HEAD
• git diff --stat origin/main...HEAD
• rg -n "<old_version>|<new_version>" Cargo.toml Cargo.lock README.md README_ZH.md flake.nix helm/rustfs/Chart.yaml rustfs.spec
• make pre-commit

Output contract

When using this skill, always report:

• Target version.
• Files changed.
• Any assumptions or uncertainties requiring confirmation.
• Verification result (PASSED or BLOCKED) with key evidence.
• Commit message(s) used.
• Push status and PR URL when GitHub flow is requested.