Azd Publish

azd Extension Publish

> Automate version bumps, changelog updates, and PR creation for waza azd extension releases.

When to Use

• Preparing a new release of the waza azd extension
• Bumping the version number (major, minor, or patch)
• Updating the changelog with changes since last release
• Creating a release PR for review

Workflow

Follow these steps in order. Ask the user for input at each decision point.

Step 1: Gather Changes and Update Changelog

Get the current version from version.txt and extension.yaml, then collect commits since the last release:

cat version.txt

# Find the latest azd extension version tags
git tag --list 'azd-ext-microsoft-azd-waza_*' --sort=-v:refname | head -5

# Get commits since last azd extension tag
last_tag=$(git tag --list 'azd-ext-microsoft-azd-waza_*' --sort=-v:refname | head -1)
git log "${last_tag}..HEAD" --oneline --no-decorate

If version.txt and extension.yaml differ, flag it to the user before proceeding.

Summarize the changes grouped by type:

• Added — feat: commits
• Fixed — fix: commits
• Changed — refactor:, chore:, docs: commits
• Removed — any removal-related commits

Present the summary to the user for review.

Then update CHANGELOG.md. The changelog follows Keep a Changelog format.

Perform these updates (using a placeholder version X.Y.Z — the actual version is determined in Step 2):

1. Move Unreleased content: Move any items currently under ## [Unreleased] into a staging area. If [Unreleased] is empty, populate from the git log summary gathered above.

1. Populate from commits: Prepare entries grouped under ### Added, ### Fixed, ### Changed as appropriate based on the commits gathered above.

Hold these changelog entries — the new version section header and comparison links will be finalized after the version is determined in Step 2.

Step 2: Determine Version

Based on the changes gathered in Step 1, recommend a version bump type using standard semver semantics:

• major — Breaking changes, removals of public API (feat!:, BREAKING CHANGE:) → (MAJOR+1).0.0
• minor — New features, backward compatible (feat:) → MAJOR.(MINOR+1).0
• patch — Bug fixes, docs, refactors, chores (fix:, docs:, refactor:, chore:) → MAJOR.MINOR.(PATCH+1)

Present the recommendation with rationale (e.g., "I see 3 feat: commits and no breaking changes — recommending a minor bump").

ASK THE USER to confirm the recommended bump or choose a different one.

Compute the new version and confirm with the user before proceeding.

Then finalize the changelog:

1. Create new version section: Insert a new section below ## [Unreleased] with today's date:

``markdown ## [X.Y.Z] - YYYY-MM-DD ``

1. Add the prepared entries from Step 1 under the new version section.

1. Update comparison links at the bottom of the file:

``markdown [Unreleased]: https://github.com/microsoft/waza/compare/azd-ext-microsoft-azd-waza_X.Y.Z...HEAD [X.Y.Z]: https://github.com/microsoft/waza/compare/azd-ext-microsoft-azd-waza_PREVIOUS...azd-ext-microsoft-azd-waza_X.Y.Z ``

1. Clear the Unreleased section: Leave ## [Unreleased] with empty subsections or blank.

Step 3: Update Version Files

Update these files with the new version:

1. version.txt — Replace contents with new version string
2. extension.yaml — Update the version: field

Step 4: Review Changes

Show the user a summary of all changes made:

• New version number
• Files modified: version.txt, extension.yaml, CHANGELOG.md
• Show the diff with git diff

Step 5: Ask About PR Creation

ASK THE USER: Should I create a PR with these changes?

If yes:

1. Create a feature branch:

``bash git checkout -b release/v{VERSION} ``

1. Stage and commit all changes:

``bash git add version.txt extension.yaml CHANGELOG.md git commit -m "chore: Prepare release v{VERSION}" ``

1. Push the branch:

``bash git push origin release/v{VERSION} ``

1. Create a PR using the GitHub CLI:

```bash gh pr create \ --title "Release v{VERSION}" \ --body "## Release v{VERSION}

### Changes {changelog entries for this version}

### Checklist

• [ ] Version bumped in version.txt and extension.yaml
• [ ] CHANGELOG.md updated
• [ ] CI passes
• [ ] Ready to publish via 'Publish azd Extension' workflow" \

--base main \ --head release/v{VERSION} ```

If no:

• Leave the changes uncommitted in the working tree
• Inform the user they can review and commit manually

File Reference

| File | Purpose | What Gets Updated | |------|---------|-------------------| | version.txt | Single source of version truth | New semver version string | | extension.yaml | azd extension manifest | version: field | | CHANGELOG.md | Human-readable change history | New version section with entries |

Important Notes

• Always use conventional commit prefixes (feat:, fix:, chore:, docs:, refactor:) when interpreting git history
• The changelog format must follow Keep a Changelog
• Version numbering must follow Semantic Versioning
• The PR branch naming convention is release/v{VERSION}
• After the PR is merged, the user should trigger the Publish azd Extension workflow (azd-ext-release.yml) to build, pack, and publish the extension

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: microsoft
• Source: microsoft/waza
• License: MIT
• Homepage: https://microsoft.github.io/waza/

Install and usage instructions live in the source repository linked above.