| name | bump-version |
| description | 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. |
| compatibility | Requires gh CLI with repo access for creating branches and pull requests. GitHub API access for PR details when performing SemVer-informed assessment. |
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 assessment logic — the SemVer assessment guide 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 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:
<VersionPrefix> — the MAJOR.MINOR.PATCH version<VersionSuffix> — 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 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:
- Get the list of PRs merged between the previous release tag and the target commit (typically HEAD).
- 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
- Compute the recommended version from the previous release tag (see the assessment guide for increment rules).
- Compare against the current version in
Directory.Build.props and flag any discrepancy.
- 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
- Create a new branch named
bump-version-to-{version} (e.g. bump-version-to-1.1.0) from the current branch
- Update
src/Directory.Build.props:
- Set
<VersionPrefix> to the confirmed stable component
- Set
<VersionSuffix> for prerelease versions, or clear it for stable versions; add the element if it is missing
- Update
<PackageValidationBaselineVersion> if the MAJOR version has changed
- Commit with message:
Bump version to {version}
- 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.
