bump-version

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 (most recent published release). 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, use the most recent published release globally. See release-branches.md for details.

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:

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 <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
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.