Bump Version

Bump Version

Overview

Standardized process for bumping to a stable release in projects with package.json and manifest.json (e.g., Obsidian plugins).

Pair skill: beta-release handles the prerelease cycle that may precede a stable bump.

When to Use

• User asks to "bump version to X.Y.Z"
• User asks to "prepare release X.Y.Z"
• User asks to "release version X.Y.Z"
• User runs /bump-version or /bump-version X.Y.Z

If the target is a X.Y.Z-beta.N prerelease, use the beta-release skill instead — its manifest/release/issue handling is different.

Process

0. Determine Version

• If version is provided as argument (e.g., /bump-version 0.13.0), use it
• If version is mentioned in user's message (e.g., "bump version to 0.13.0"), use it
• Otherwise, ask user: "What version should I bump to?"

Check for a preceding beta cycle. Read package.json's current version: if it's X.Y.Z-beta.N, this stable bump is the close-out of a beta cycle and the CHANGELOG entry for X.Y.Z should already exist (drafted during the beta-release run). In that case reuse and amend the existing entry — add any follow-up fixes that landed during the beta — rather than writing it from scratch. Also remember manifest.json was held at the previous stable during the beta; this is the bump where it finally moves to X.Y.Z.

1. Update Version Files

Update the version field in:

• package.json
• manifest.json (if exists, e.g., Obsidian plugins)

2. Analyze Changes Since Last Release

Find the latest stable release tag (excludes beta/rc tags):

LAST_STABLE=$(git tag --list --sort=-v:refname | grep -E '^[0-9]+\.[0-9]+\.[0-9]+$' | head -1)
git log --oneline ${LAST_STABLE}..HEAD

IMPORTANT: User perspective, not commit history

CHANGELOG is for end users, not developers. Write from the user's perspective:

• What new capabilities can they use?
• What existing behavior changed?
• What bugs that affected them are fixed?

Do NOT include:

• Internal refactoring (unless it affects users)
• Bug fixes for features introduced in the same release cycle
• Intermediate fixes made during development of a new feature
• Implementation details (API changes, code structure)

Example - What to exclude: If commits show:

feat: add OpenAI integration
fix: OpenAI token limit error
fix: OpenAI settings UI positioning
refactor: use requestUrl API for OpenAI

Only the first commit matters for CHANGELOG. The fixes are for bugs introduced during development of the new feature - users never experienced them.

Categorize changes into sections:

• Added: New features users can now use
• Changed: Changes to existing functionality users will notice
• Fixed: Bug fixes for issues that existed in previous releases
• Improved: Performance or UX improvements users will notice

3. Update CHANGELOG.md

Feature sessions maintain a ## [Unreleased] section as work lands (see repo CLAUDE.md → Changelog). If one exists, rename it to ## [X.Y.Z] - YYYY-MM-DD and add anything missed, rather than writing from scratch. Otherwise create the section.

Follow Keep a Changelog format:

## [x.x.x] - YYYY-MM-DD

### Added
- New feature description (#issue)

### Changed
- Change description (#issue)

### Fixed
- Bug fix description (#issue)

Include issue/PR numbers where applicable: (#123)

Verify each entry against the user-facing surface. Commit descriptions tell why and how a change was made; CHANGELOG entries tell what the user sees. These diverge in small but visible ways — e.g. a UI control described as a "slider" that's actually addText (number input); a fix said to affect "the sidebar" that also affects the in-document panel; a setting whose label in code differs from the working name in the commit. Before finalizing each entry, open the component that implements the change and confirm: control type, exact label, and which views are affected. A 30-second read prevents a user-caught inaccuracy at review time.

4. Commit Changes

git commit -m "chore: bump version to X.Y.Z"

If the user only asked to prepare the bump, stop here and let them review + release. If the user delegated the release to you ("release it", "릴리즈까지 진행해줘"), continue to step 5.