version-bump

What this skill does

# Version Bump

## Purpose

Reads the current version from any project type (Node.js, Python, Rust, Go, Java, generic, Claude Code plugins), analyzes git commits since the last release tag, and calculates the appropriate semantic version bump (major/minor/patch) based on conventional commit patterns. Supports multiple version files kept in sync.

## Input Context

Requires:
- **Project Configuration**: Output from `detect-project-type` skill
- **Version Type** (optional): "major", "minor", "patch", or "auto" (default)

## Workflow

### 1. Load Project Configuration

Use configuration from `detect-project-type`:
- Project type
- Version file paths and adapters
- Tag pattern
- Conventional commits enabled/disabled

### 2. Read Current Version

Use the Read tool to read the primary version file and extract the version. See [Version Adapters Reference](../../docs/version-adapters.md) for detailed adapter implementations.

**For JSON files (package.json, plugin.json):**
1. Use Read tool to read the JSON file
2. Parse JSON content to extract the "version" field value
3. Store the extracted version as current_version

**For TOML files (Cargo.toml, pyproject.toml):**
1. Use Read tool to read the TOML file
2. For Cargo.toml: Search for line starting with "version = " in the [package] section
3. For pyproject.toml: Search in [project] or [tool.poetry] section for "version = "
4. Extract the version value from between the quotes
5. Store as current_version

**For Python __version__.py files:**
1. Use Read tool to read the __version__.py file
2. Search for line starting with "__version__ = "
3. Extract the version string from between the quotes
4. Store as current_version

**For text files (VERSION, version.txt):**
1. Use Read tool to read the file
2. The entire file content (with whitespace trimmed) is the version
3. Store as current_version

**For Gradle files:**
1. Use Read tool to read gradle.properties or build.gradle
2. For gradle.properties: Search for line "version=" and extract value after the =
3. For build.gradle: Search for line "version = " and extract value from between quotes
4. Store as current_version

**For Maven pom.xml:**
1. Use Read tool to read pom.xml
2. Search for the first <version> tag in the project section
3. Extract the version value between <version> and </version> tags
4. Store as current_version

**For Go projects (git tags only):**
1. Use Bash tool: `git describe --tags --abbrev=0 2>/dev/null`
2. If successful, remove the 'v' prefix if present (e.g., "v1.2.3" → "1.2.3")
3. If no tags exist, use "0.0.0" as default
4. Store as current_version

**For multiple version files:**
1. Read version from the primary file (first in list) using appropriate method above
2. Read version from each secondary file using appropriate method
3. Compare all versions - if they don't match, warn the user with version mismatch details
4. Use the primary file's version as current_version

### 3. Find Last Release Tag

Use the tag pattern from project configuration to find the most recent release tag:

1. Get the tag_pattern from project configuration (e.g., "v{version}", "{package}-v{version}")
2. Convert the pattern to a git tag search pattern:
   - `v{version}` → search for `v*`
   - `{package}-v{version}` → search for `{package}-v*`
3. Use Bash tool to list tags: `git tag -l "v*" --sort=-version:refname` (adjust pattern as needed)
4. Take the first (most recent) tag from the sorted list
5. Store as last_tag

**If no tag exists:**
- This is likely the first release
- Use current version from file as baseline
- The bump type will be "initial" (not a bump, but initial release)

### 4. Analyze Commits Since Last Release

Get the list of commits to analyze for version bump determination:

1. If last_tag exists:
   - Use Bash: `git log {last_tag}..HEAD --format="%s" --no-merges` to get commit messages since the tag
2. If no last_tag (first release):
   - Use Bash: `git log --format="%s" --no-merges` to get all commit messages
3. Store the list of commit messages for parsing

### 5. Parse Conventional Commits

If `conventional_commits` is enabled in configuration (default: true), analyze each commit message:

**Major Bump Indicators (breaking changes):**
- Commit message contains `BREAKING CHANGE:` or `BREAKING-CHANGE:` anywhere
- Commit type followed by exclamation mark: `feat!:`, `fix!:`, `refactor!:`, etc.

**Minor Bump Indicators (new features):**
- Commit starts with `feat:` or `feat(scope):`

**Patch Bump Indicators (bug fixes and other):**
- Commit starts with `fix:` or `fix(scope):`
- Other conventional types: `chore:`, `docs:`, `style:`, `refactor:`, `test:`, `perf:`

**Analysis Process:**
1. Initialize counters: breaking_count=0, feat_count=0, fix_count=0
2. For each commit message in the list:
   - Check if it contains "BREAKING CHANGE:" or "BREAKING-CHANGE:", increment breaking_count
   - Check if it matches pattern `*!:*` (type with exclamation), increment breaking_count
   - Check if it starts with "feat:" or "feat(*", increment feat_count
   - Check if it starts with "fix:" or "fix(*", increment fix_count
3. Store the counts for use in determining bump type

**If `conventional_commits` is disabled:**
- Default to patch bump for any commits (unless explicit version type was provided by user)

### 6. Determine Bump Type

Apply precedence rules to determine the semantic version bump:

1. **If user provided explicit version type** (major/minor/patch via argument):
   - Use the explicit type, ignoring commit analysis
   - Set bump_type to the user's choice
   - Add reasoning: "Explicit {type} bump requested by user"

2. **Else if breaking_count > 0:**
   - Set bump_type = "major"
   - Add reasoning: "{breaking_count} breaking change(s) detected → major bump"

3. **Else if feat_count > 0:**
   - Set bump_type = "minor"
   - Add reasoning: "{feat_count} feature(s) added → minor bump"

4. **Else if fix_count > 0 or any other commits exist:**
   - Set bump_type = "patch"
   - Add reasoning: "{fix_count} fix(es) applied → patch bump" or "Commits detected → patch bump (default)"

5. **Else (no commits since last tag):**
   - Set bump_type = "none"
   - Add reasoning: "No new commits since last release"

**Special case: Initial release (no last tag):**
- If current version is 0.x.x, treat as pre-1.0 (no bump needed)
- If current version is 1.0.0+, use as-is
- Otherwise, default to 1.0.0

### 7. Calculate New Version

Parse the current version and calculate the new version based on bump type:

1. **Parse the current version** (format: X.Y.Z):
   - Split current_version by '.' to get major, minor, patch numbers
   - If patch has pre-release metadata (e.g., "3-alpha"), extract only the numeric part
   - Store major, minor, patch as integers

2. **Calculate new version based on bump_type:**
   - **If bump_type is "major":**
     - Increment major by 1
     - Reset minor and patch to 0
     - new_version = "{major+1}.0.0"

   - **If bump_type is "minor":**
     - Keep major unchanged
     - Increment minor by 1
     - Reset patch to 0
     - new_version = "{major}.{minor+1}.0"

   - **If bump_type is "patch":**
     - Keep major and minor unchanged
     - Increment patch by 1
     - new_version = "{major}.{minor}.{patch+1}"

   - **If bump_type is "none" or "initial":**
     - Keep version unchanged
     - new_version = current_version

3. Store new_version for output

### 8. Generate Reasoning

Create a human-readable list explaining the version bump decision:

1. Initialize an empty reasoning list
2. Add reasoning based on what was detected:
   - If breaking_count > 0: Add "{breaking_count} breaking change(s) detected → major bump"
   - If feat_count > 0: Add "{feat_count} feature(s) added → minor bump"
   - If fix_count > 0: Add "{fix_count} fix(es) applied → patch bump"
3. If multiple bump indicators exist, add a note about precedence (e.g., "Major bump takes precedence")
4. If no conventional commits were found, add "No conventional commits found → patc