bump-aspire-version

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:

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:

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.