bump-aspire-version

---
name: bump-aspire-version
description: Bumps the Aspire repository product version in eng/Versions.props using previous version-bump commits as guidance. Use when asked to bump Aspire branding, advance the repository to a new major or minor version, or create a version-bump PR. Not for external dependency, SDK, or container-image updates.
---

# Bump the Aspire repository version

The product version is defined in the first property group of `eng/Versions.props`.
Keep the target branch's automatic milestone assignment aligned in
`.github/policies/milestoneAssignment.prClosed.yml`. Do not replace every occurrence
of the old version throughout the repository.

## Inspect the target and history

1. Establish the requested version and target branch. Interpret `X.Y` as `X.Y.0`.
   Ask if the target version is missing; do not infer it from the calendar or SDK.
2. Read the working-tree status and preserve unrelated changes. Use the current
   session branch and follow any app-managed branch naming requirements.
3. Read both files and inspect previous bumps, including their complete diffs so
   related automation changes are not missed:

   ```bash
   git log -8 --oneline -G '<MajorVersion>|<MinorVersion>|<PatchVersion>|AspireDashboardImageTag' -- eng/Versions.props
   git log -5 --oneline -- .github/policies/milestoneAssignment.prClosed.yml
   git show <relevant-commit>
   ```

   Useful precedents are #19139 (`be77aa36da`, 13.5 to 13.6) and #20037
   (`1fd72c6d05`, 13.6 to 14.0 with an unpublished dashboard-image workaround).
   Prefer the latest applicable history over copying an old diff blindly.
4. Confirm the exact target milestone exists and is open in GitHub. If it is
   missing or closed, ask before creating or reopening it; do not leave the policy
   pointing at a milestone the bot cannot assign.

## Run the deterministic edit

Use the bundled C# file-based app with the repository's .NET SDK rather than
generating ad-hoc editing code.
From the repository root, substitute the requested version, target branch, and
confirmed open milestone:

```bash
dotnet run --file .agents/skills/bump-aspire-version/BumpVersion.cs -- 17.0 --branch main --milestone 17.0
```

`--branch` is the PR's target branch, not the feature branch. `--milestone` is
explicit because servicing milestones can differ from product versions (for
example, product `13.6.1` can use milestone `13.6.x`). The script does not create,
reopen, or query GitHub milestones; confirm availability in the previous step.

The script updates all three version components (`X.Y` means `X.Y.0`) and exactly
one matching branch's milestone rule. It validates the expected file structure
before writing either file and fails on missing or ambiguous matches. It preserves
formatting, line endings, unrelated rules, and all other properties. Repeating the
same command makes no further changes. If the file layout changes, update the
script rather than bypassing its checks.

Prerelease/stabilization settings and the dashboard-image pin remain unchanged:
a product version bump neither stabilizes packages nor publishes a dashboard image.
Review any version-specific comments separately. Do not change other release-branch
rules, dependencies, SDKs, generated APIs, or sample versions without explicit scope.
The old `.github/workflows/milestone-assignment.yml` was removed in #20390 in favor
of the policy bot; do not recreate it.

## Validate

Review `git diff --check` and the complete diff. Confirm only the intended version
properties, milestone assignment, and any directly related comments changed.

Confirm the resulting version components and milestone title match the request.
Run the edit command again and confirm it reports both files unchanged.

Check the diff separately to confirm prerelease settings and the dashboard-image
pin were preserved. If the change extends beyond metadata, run focused validation
for that behavior and follow the repository's SDK setup instructions when needed.

## Create the PR when requested

Use the `create-pr` skill and the repository PR template. Commit only the intended
files, include required commit trailers, push without force, and use the available
PR creation tool when the environment requires it. Describe the old and new
versions, milestone routing, unchanged prerelease status, any retained
dashboard-image override, and the validation actually performed.
Do not claim a full build or test run unless
one was performed. Do not merge automatically.

More agent context in dotnet/aspire

24 other files this repository gives its agents.

Also found in one other repository

The same file, byte for byte, in the weekly crawl of public GitHub.

• microsoft/aspire6.3k