refresh-arm-sdk-release

name	refresh-arm-sdk-release
description	**WORKFLOW SKILL** — Prepares Azure.ResourceManager SDK refresh pull requests in azure-sdk-for-net. WHEN: "prepare sdk refresh", "refresh Azure.ResourceManager package", "update ARM SDK from autorest tag", "refresh changelog dependencies". INVOKES: git and GitHub pull request tools for branch, commit, push, and PR creation. FOR SINGLE OPERATIONS: Use git or GitHub tools directly.

Refresh ARM SDK Release Skill

When to Use This Skill

Activate only when the user wants an Azure.ResourceManager package refresh PR driven by API-version/tag resolution and dependency/changelog refresh updates.

Scope Boundaries

• Use this skill only for refresh-style updates (for example regenerated surface alignment, changelog maintenance, dependency version refresh, and refresh PR creation).
• Do not use this skill for broad or feature-driven package releases, release planning across multiple packages, or non-refresh release orchestration.

Prerequisites

• Repository: azure-sdk-for-net
• Target package path is known, for example sdk/dns/Azure.ResourceManager.Dns
• Access to remote origin and GitHub PR creation
• Current date available in yyyy-mm-dd format

Workflow

Step 1: Create Branch

• Fetch latest origin/main.
• Create a new branch from origin/main.
• Use a branch name that identifies package and date.

Step 2: Eligibility Check — Skip Conditions

Before doing any further work on a package, check the CHANGELOG.md and skip the package (do not refresh it) if either of the following is true:

1. Already released: The latest changelog entry does NOT contain (Unreleased) — it already has a release date (e.g., ## 1.2.0 (2026-04-17)). This means a release was already prepared and no new (Unreleased) entry exists to stamp.
2. Dependencies already up to date: Any changelog entry (across all released versions, not just the latest) already contains upgrade lines for both the current Azure.Core and Azure.ResourceManager versions (resolved from eng/centralpackagemanagement/Directory.Packages.props). If these exact versions were already shipped in any prior release, adding them again provides no value, so skip.

When skipping a package, log it clearly as SKIPPED with the reason, and move on to the next package in the batch.

Step 3: Determine API Version Source in Order

• Check metadata.json in the package root.
• If present, use apiVersions value.
• If metadata.json is missing, check src/autorest.md for an uncommented tag.
• If tag is missing there, use the require value in src/autorest.md to open the referenced readme.md and read tag under Basic Information.

Step 4: Decide SDK Versioning Mode

• If API version source indicates preview, use beta flow.
• Otherwise use stable flow.

Step 5: Update CHANGELOG.md

• Confirm the newest heading exists and has the latest package version.
• During release finalization, replace Unreleased with current date using yyyy-mm-dd.
• For stable flow only, determine the new stable version using this logic:
  1. Find the latest released version in the CHANGELOG — the first entry that does NOT have (Unreleased).
  2. If the latest released version is stable (e.g., 1.1.1): increment its patch to get the new version (e.g., 1.1.2).
  3. If the latest released version is beta (e.g., 1.1.0-beta.7): strip the pre-release suffix to get the new version (e.g., 1.1.0). This handles promotion when the most recent work was done as beta.
  4. If no released version exists at all (every entry is Unreleased or the changelog is empty): use 1.0.0.
• Update the unreleased entry's heading to reflect the new stable version.
• Remove empty sections under the latest entry when present:
  • Features Added
  • Breaking Changes
  • Bugs Fixed
• Under Other Changes, add:
  • Upgraded dependent Azure.Core to 1.X.X.
  • Upgraded dependent Azure.ResourceManager to 1.X.X.
• Always resolve these exact versions from eng/centralpackagemanagement/Directory.Packages.props at the time of refresh — do not hardcode or cache version numbers, as they may change between batches.

Step 6: Update Project Version for Stable Flow Only

• If stable flow, set Version in src/Azure.ResourceManager.XXX.csproj to the new stable version matching the changelog entry.
• If beta flow, keep beta versioning and do not apply a version bump.

Step 6b: Update README for First Stable Release

• This applies only when there is no prior stable release in the CHANGELOG (only beta entries exist).
• Add the line This is the first stable release of this library. immediately after the version heading (before any sections).
• Open README.md in the package root and find the dotnet add package installation command.
• If it contains --prerelease, remove that flag so the command installs the stable package.
• Example: dotnet add package Azure.ResourceManager.XXX --prerelease → dotnet add package Azure.ResourceManager.XXX

Step 7: Commit, Push, and Create PR

• Commit with a refresh-focused message.
• Push branch to origin.
• Create PR with title format:
  • Prepare release for Azure.ResourceManager.XXX Version 1.x.x
• Include summary of API source decision, refresh changes, and versioning mode.

Copyable Checklist

Refresh PR progress:

• Branch created from origin/main
• Eligibility checked — packages with no Unreleased entry or already-current deps skipped
• API version source resolved using required precedence
• Beta or stable mode decided
• Changelog latest entry updated
• Unreleased replaced with current date yyyy-mm-dd
• Dependency upgrade lines added using central package versions
• Csproj version updated if stable flow
• README --prerelease flag removed if first stable release (version 1.0.0)
• Commit and push completed
• PR created with required title format