# Bump Version > Assess and bump the SDK version using Semantic Versioning 2.0.0. Evaluates queued changes to recommend PATCH/MINOR/MAJOR, updates src/Directory.Build.props, and creates a pull request. Owns the SemVer assessment logic shared by prepare-release and publish-release. Use when asked to bump the version, assess the version, or determine what the next version should be. - Skill: `gabrielmoreira/bump-version` (Agent Skill) - Install (CLI): `npx skillmds@latest add gabrielmoreira/bump-version` - Raw SKILL.md: https://api.skillmd.com/api/skills/gabrielmoreira/bump-version/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: gabrielmoreira (https://skillmd.com/u/gabrielmoreira) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/gabrielmoreira/bump-version --- # Bump Version Assess and bump the SDK version in `src/Directory.Build.props` to prepare for the next release. This skill owns the [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html) assessment logic — the [SemVer assessment guide](references/semver-assessment.md) is the single source of truth for version assessment criteria used across the release workflow by both the **prepare-release** and **publish-release** skills. Use the shared [release branch reference](../shared-resources/release-branches.md) for branch roles, previous-release lookup rules, and release work-branch naming. > **Note**: For comprehensive release preparation — including ApiCompat/ApiDiff, documentation review, and release notes — use the **prepare-release** skill, which incorporates version assessment as part of its broader workflow. ## Process ### Step 1: Read Current Version and Previous Release Read `src/Directory.Build.props` on the current branch and extract: - `` — the `MAJOR.MINOR.PATCH` version - `` — the prerelease suffix, when present The candidate version is `{VersionPrefix}` plus `-{VersionSuffix}` when the suffix is present (for example, `2.0.0-preview.1`). Display the current candidate version to the user. Determine the previous release tag from `gh release list` — the **highest semver** among published releases that are ancestors of the target commit, not the most recently published by date. Draft releases must be ignored — they represent a pending release that has not yet shipped. Use `--exclude-drafts` or filter to only published releases when querying. The lookup is branch-aware: from a `release/{MAJOR}.x` branch, restrict candidates to tags matching `v{MAJOR}.*`; from `main`, there is no MAJOR filter. See [release-branches.md](../shared-resources/release-branches.md#previous-release-tag-lookup) for details, including why date ordering picks the wrong tag. ### Step 2: Assess and Determine Next Version If the user provided a target version in their prompt, use it directly. Otherwise, determine the next version using one of two approaches: #### SemVer-Informed Assessment (Preferred) When context about queued changes is available or can be gathered, assess the version following the [SemVer assessment guide](references/semver-assessment.md): 1. Get the list of PRs merged between the previous release tag and the target commit (typically HEAD). 2. Classify the release level: - **MAJOR** — if any confirmed breaking changes (API or behavioral), excluding `[Experimental]` APIs - **MINOR** — if new public APIs, features, or obsoletion warnings are present - **PATCH** — otherwise 3. Compute the recommended version from the previous release tag (see the assessment guide for increment rules). 4. Compare against the current version in `Directory.Build.props` and flag any discrepancy. 5. Present the assessment with a summary table and rationale, then get user confirmation. #### Default Suggestion (Fallback) When a quick bump is needed without full change analysis, suggest based on the candidate version: - **Stable candidate** — suggest the next **minor** version: - Current `1.0.0` → suggest `1.1.0` - Current `1.2.3` → suggest `1.3.0` - **Prerelease candidate** — if the suffix starts with an identifier such as `preview.` or `rc.` followed by an integer, suggest incrementing the trailing integer: - Current `2.0.0-preview.1` → suggest `2.0.0-preview.2` - Current `2.0.0-rc.1` → suggest `2.0.0-rc.2` Present the suggestion and let the user confirm or provide an alternative. Parse the confirmed version into its `VersionPrefix` and `VersionSuffix` components. Stable versions have no suffix. ### Step 3: Create Pull Request 1. Create a new branch named `bump-version-to-{version}` (e.g. `bump-version-to-1.1.0`) from the current branch 2. Update `src/Directory.Build.props`: - Set `` to the confirmed stable component - Set `` for prerelease versions, or clear it for stable versions; add the element if it is missing - Update `` if the MAJOR version has changed 3. Commit with message: `Bump version to {version}` 4. Push the branch and create a pull request: - **Title**: `Bump version to {version}` - **Label**: `infrastructure` - **Base**: the current branch (which, for a servicing branch like `release/1.x`, is that servicing branch — not `main`) ### Step 4: Confirm Display the pull request URL to the user.