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 (opens in a new tab) 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.

2. 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:

   markdownCopy

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

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

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

   markdownCopy

   [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

4. 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:

   bashCopy

   git checkout -b release/v{VERSION}

2. Stage and commit all changes:

   bashCopy

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

3. Push the branch:

   bashCopy

   git push origin release/v{VERSION}

4. Create a PR using the GitHub CLI:

   bashCopy

   gh pr create \
   
   
   
   
   
   
   
   
   
   
   
   
   

If no:

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

File Reference

Important Notes

• Always use conventional commit prefixes (feat:, fix:, chore:, docs:, refactor:) when interpreting git history
• The changelog format must follow Keep a Changelog (opens in a new tab)
• Version numbering must follow Semantic Versioning (opens in a new tab)
• 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