Release process¶

AzureLocal/platform uses release-please to automate versioning and tag creation based on Conventional Commits.

The loop¶

PR merged → release-please parses log → release PR opened/updated → merge → tag + GitHub Release

No one hand-edits CHANGELOG.md or creates tags manually. Every step after a PR is merged is automated.

Version bumps¶

release-please decides the bump from commit types:

Tag format¶

azurelocal-platform-v<MAJOR>.<MINOR>.<PATCH>

Consumers pin to the short major tag (v1, v2) — not the full tag. See workflow versioning.

Cutting a release¶

1. Land all the PRs you want in the release (squash-merged to main).
2. Check the open release-please PR — confirm the proposed version and changelog entries look right.
3. Merge the release PR.
4. release-please creates the git tag and GitHub Release automatically.

5. Update the short major tag to point at the new release:

   git fetch origin --tags
   git tag -f v<MAJOR> azurelocal-platform-v<MAJOR>.<MINOR>.<PATCH>
   git push origin -f v<MAJOR>
   

   This step moves v1 (or v2, etc.) forward so existing consumer pins pick up the new patch/minor. Only do this when the release is backwards-compatible with the major.

Current version state¶

While platform is pre-stable (v0.x.x), consumers reference @main — the @v1 pin rule activates at v1.0.0. See governance/versioning for the full policy.

What release-please updates¶

Troubleshooting¶