refresh-arm-sdk-release

# 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